5 ms·

Converting existing users to systemd-homed managed users

29 points by modinfo 1y ago

Valodim 1y ago
> Please note that this specification assumes that JSON numbers may cover the full integer range of -2^63 … 2^64-1 without loss of precision (i.e. INT64_MIN … UINT64_MAX). Please read, write and process user records as defined by this specification only with JSON implementations that provide this number range. Wait, so.. not javascript?
- chao- 1y ago
  Interesting catch. Don't many desktop Linux utilities from the GNOME project use JavaScript?
  - mpyne 1y ago
    And from KDE as well, through Qt's Qt Declarative libraries that use QML. Judging by the Qt source, if the internal JS runtime JSON parser is used then it will not support full range of 64-bit integers, since the double floating point type is used for any integers x where abs(x) > 1^^25.
  - stonogo 1y ago
    Most (all?) systems running systemd are going to have a javascript interpreter as a polkit dependency anyway.
- deathanatos 1y ago
  It's not the default, but JS is capable of this. (JavaScript has a big integer type nowadays, and the JSON.parse function's "reviver" parameter I think should be capable of parsing to bigints, but you'd need to specify such a reviver.) Something like this, I think: JSON.parse( /* just a test input JSON */ `{"a": 1.1, "b": 22222222222222222222222222222222, "c": {"d": 999999999999999999999999}}`, /* a reviver that returns BigInts, if it's an integer. */ (key, value, context) => { if(typeof value === "number" && /^[0-9]+$/.test(context.source)) { return BigInt(context.source); } else { return value; } } );
deleted 1y ago
[deleted]
WCSTombs 1y ago
> With the advent of systemd-homed it might be desirable to convert an existing, traditional user account to a systemd-homed managed one. As someone unfamiliar with systemd-homed, I have a very basic question: why would someone want (or not want) to do this?
- ocdtrekkie 1y ago
  Based on... a web search: https://wiki.archlinux.org/title/Systemd-homed https://wiki.archlinux.org/title/Systemd-homed The big thing appears to be moving the user metadata into the home directory itself rather than it being around the system, and enabling home folder encryption, which has been like... a single button press feature on Windows since like Windows XP. Sounds like a step forward.
  - yjftsjthsd-h 1y ago
    I'm slightly confused. I understand the appeal to putting user configuration inside the home directory, and I definitely approve of encrypting each home directory individually, but doesn't doing both of them together mean that you can't read the user data until it's been decrypted?
    - 0xCMP 1y ago
      The encrypted volume has an encrypted copy of the `~/.identity` file in it's metadata fields. The same key which encrypts the volume decrypts the metadata, but they use different IVs. You could assume that most systems the key would be secured with the TPM so this won't be much of a big deal to the user, but otherwise when they try to login it would prompt for this password first.
    - throw0101d 1y ago
      > * I understand the appeal to putting user configuration inside the home directory* […] I'm not sure I understand the appeal. What does "putting user configuration inside the home directory" mean in this context? Is there a file with the UID, GIDs (primary, secondaries), GECOS, etc? What is put inside the homedir?
sgarland 1y ago
I don’t understand the obsession with systemd managing everything. I do not want it to manage my logs, NTP, DNS resolution, and I sure as hell don’t want it to manage /home.
- strawhatguy 1y ago
  Yeah big nope on this. Needs to be separate, if it’s useful at all, not systemd “separate”. I don’t run systemd at all, to be safe.
  - aryonoco 1y ago
    Stay safe! Meanwhile, I want to be able to mount my home directory on an external drive, and have it shared between systems without UID/GID hell. And, Have an encrypted home directory and boot the system and be able to enter my password with my keyboard which is connected to a thunderbolt dock during boot. Something which has been possible on Mac and windows for a decade or two. Systemd-homed is the ONLY way to achieve these (and many others) in Linux. Criticisms of systemd just because “it doesn’t smell like Unix” is all nice and fine, but ignores real quality of life and security features it provides. If you don’t have these usecases, you’re welcome to continue to ignore systemd, but some of us actually want these feature.
    - msgodel 1y ago
      You're comfortable sharing secret keys between systems?
      - bombcar 1y ago
        The keys would definitely be secreted hehehe
    - yjftsjthsd-h 1y ago
      > Systemd-homed is the ONLY way to achieve these (and many others) in Linux. It absolutely is not. [Full] disk encryption has been fine for... at least 15 years, probably more. Sharing a home directory requires consistent UID/GID, but that's not hard even fully manually (which is fine if you're just one person).
themafia 1y ago
The continued pathology of systemd. You can't use d-bus for this because d-bus isn't available early enough, relies on user accounts, and can't enumerate through large sets of objects with optional filtering they had to create and invoke the completely separate "Varlink." Which is _closer_ to the traditional Unix/Plan9 service model without actually achieving it meaningfully. The infamous part of d-bus, that it helps inject arbitrary binary payloads into existing text protocols, is now reversed in varlink, it takes what should be arbitrary binary payloads (user records, certificates, etc..) and instead forces you to manage them as JSON objects. Signing and conveying signatures for this object are predictably painful. "The signature section contains one or more cryptographic signatures of a reduced version of the user record. This is used to ensure that only user records defined by a specific source are accepted on a system, by validating the signature against the set of locally accepted signature public keys. The signature is calculated from the JSON user record with all sections removed, except for regular, privileged, perMachine. Specifically, binding, status, signature itself and secret are removed first and thus not covered by the signature. This section is optional, and is only used when cryptographic validation of user records is required (as it is by systemd-homed.service for example)." This all seems very brittle and I don't see the kinds of testing that would project confidence in this system. Good luck to all who use this and trust it.
- surajrmal 1y ago
  Ultimately ipc, service discovery, and security all need to be codesigned to work together. Systemd is unfortunately trying to work in an ecosystem where it does not have the luxury of a clean first principles approach. Generally I would argue moving off of dbus and onto varlink is in the right direction. I'm not sure what you think is brittle about the approach of using ipc and a schema for the data sent over it. If they had gone in the other direction and mandated grpc ala http instead, would that have been "less brittle"?
  - amluto 1y ago
    That IMO does not, in any respect, excuse the signature design. This JSON+blobs design is totally new other than needing to support a handful of preexisting fields. And it’s very much the case that a lot of the record is trusted in the sense that loading malicious data could compromise the integrity or availability of the machine. So structure it like that! Have a whole file that is signed or otherwise integrity-checked in its entirely. Have another file with fields that are per-(user,machine) and integrity-check that. “Integrity-check” means that you validate the binary contents of the file before you even attempt to parse it, and then you parse the literal bytes that you checked. It’s not the nineties anymore, and architects should know better.
aryonoco 1y ago
For those curious about systemd-homed, lwn had a writeup about a discussion in Fedora about it which provides a good summary of the pros and cons of systemd-homed. https://lwn.net/Articles/995915/ https://lwn.net/Articles/995915/
throw0101d 1y ago
It seems to be that a lot of what systemd is doing (over and above being 'just' an init system) seems to be focused on standalone systems. And that's fine and all for some folks, but for those of us sysadmin-ing servers/VMs, it's all sorts of annoying that these sub-systems exist for dynamic environments (laptops using networkd/resolvd/etc to handle moving around), but I just want my system to be static and not have (e.g.) resolv.conf futzed around with (I've taken to doing a chattr +i on the file quite often).
- nixosbestos 1y ago
  Hm. So then don't use (systemd-)resolved? Alternatively, I've accepted that it's built to work with a decades-old ecosystem and that resolv.conf is effectively a generated, read-only-except-resolved file. And in turn, resolved's configuration is perfectly static and equally immutable. /shrug My* only problem is that it's pretty good at what it does, and can be... more helpful than you might like at providing consistent global DNS resolution. For example, it's use over dbus makes processes in `netns`s susceptible to leaking DNS requests. Though arguably I should've been going more full-containery than just a netns maybe, given my expectations.
  - throw0101a 1y ago
    > Hm. So then don't use (systemd-)resolved? The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable. Changing the IP address was also fairly simple in editing a file, but now there's networkd sometimes, and NetManager other times, and netplan too, and perhaps make sure your YAML file is indented with the right number of spaces in the right place…
    - yjftsjthsd-h 1y ago
      > The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable. In many years of daily-driving unix-likes and being an amateur and professional sysadmin, I think resolv.conf is the only time I've ever actually used `chattr +i`.
- 1y ago
erlkonig 1y ago
<tirade style="justified"> F*k systemd, and systemd-homed along with it. Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn. Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight. Looking through the doc at https://systemd.io/HOME_DIRECTORY/ https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems. I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash. </tirade>

29 points by modinfo 1y ago

> Please note that this specification assumes that JSON numbers may cover the full integer range of -2^63 … 2^64-1 without loss of precision (i.e. INT64_MIN … UINT64_MAX). Please read, write and process user records as defined by this specification only with JSON implementations that provide this number range. Wait, so.. not javascript?

chao- 1y ago
Interesting catch. Don't many desktop Linux utilities from the GNOME project use JavaScript?
- mpyne 1y ago
  And from KDE as well, through Qt's Qt Declarative libraries that use QML. Judging by the Qt source, if the internal JS runtime JSON parser is used then it will not support full range of 64-bit integers, since the double floating point type is used for any integers x where abs(x) > 1^^25.
- stonogo 1y ago
  Most (all?) systems running systemd are going to have a javascript interpreter as a polkit dependency anyway.
deathanatos 1y ago
It's not the default, but JS is capable of this. (JavaScript has a big integer type nowadays, and the JSON.parse function's "reviver" parameter I think should be capable of parsing to bigints, but you'd need to specify such a reviver.) Something like this, I think: JSON.parse( /* just a test input JSON */ `{"a": 1.1, "b": 22222222222222222222222222222222, "c": {"d": 999999999999999999999999}}`, /* a reviver that returns BigInts, if it's an integer. */ (key, value, context) => { if(typeof value === "number" && /^[0-9]+$/.test(context.source)) { return BigInt(context.source); } else { return value; } } );

deleted 1y ago

[deleted]

WCSTombs 1y ago

> With the advent of systemd-homed it might be desirable to convert an existing, traditional user account to a systemd-homed managed one. As someone unfamiliar with systemd-homed, I have a very basic question: why would someone want (or not want) to do this?

ocdtrekkie 1y ago
Based on... a web search: https://wiki.archlinux.org/title/Systemd-homed https://wiki.archlinux.org/title/Systemd-homed The big thing appears to be moving the user metadata into the home directory itself rather than it being around the system, and enabling home folder encryption, which has been like... a single button press feature on Windows since like Windows XP. Sounds like a step forward.
- yjftsjthsd-h 1y ago
  I'm slightly confused. I understand the appeal to putting user configuration inside the home directory, and I definitely approve of encrypting each home directory individually, but doesn't doing both of them together mean that you can't read the user data until it's been decrypted?
  - 0xCMP 1y ago
    The encrypted volume has an encrypted copy of the `~/.identity` file in it's metadata fields. The same key which encrypts the volume decrypts the metadata, but they use different IVs. You could assume that most systems the key would be secured with the TPM so this won't be much of a big deal to the user, but otherwise when they try to login it would prompt for this password first.
  - throw0101d 1y ago
    > * I understand the appeal to putting user configuration inside the home directory* […] I'm not sure I understand the appeal. What does "putting user configuration inside the home directory" mean in this context? Is there a file with the UID, GIDs (primary, secondaries), GECOS, etc? What is put inside the homedir?

sgarland 1y ago

I don’t understand the obsession with systemd managing everything. I do not want it to manage my logs, NTP, DNS resolution, and I sure as hell don’t want it to manage /home.

strawhatguy 1y ago
Yeah big nope on this. Needs to be separate, if it’s useful at all, not systemd “separate”. I don’t run systemd at all, to be safe.
- aryonoco 1y ago
  Stay safe! Meanwhile, I want to be able to mount my home directory on an external drive, and have it shared between systems without UID/GID hell. And, Have an encrypted home directory and boot the system and be able to enter my password with my keyboard which is connected to a thunderbolt dock during boot. Something which has been possible on Mac and windows for a decade or two. Systemd-homed is the ONLY way to achieve these (and many others) in Linux. Criticisms of systemd just because “it doesn’t smell like Unix” is all nice and fine, but ignores real quality of life and security features it provides. If you don’t have these usecases, you’re welcome to continue to ignore systemd, but some of us actually want these feature.
  - msgodel 1y ago
    You're comfortable sharing secret keys between systems?
    - bombcar 1y ago
      The keys would definitely be secreted hehehe
  - yjftsjthsd-h 1y ago
    > Systemd-homed is the ONLY way to achieve these (and many others) in Linux. It absolutely is not. [Full] disk encryption has been fine for... at least 15 years, probably more. Sharing a home directory requires consistent UID/GID, but that's not hard even fully manually (which is fine if you're just one person).

themafia 1y ago

The continued pathology of systemd. You can't use d-bus for this because d-bus isn't available early enough, relies on user accounts, and can't enumerate through large sets of objects with optional filtering they had to create and invoke the completely separate "Varlink." Which is _closer_ to the traditional Unix/Plan9 service model without actually achieving it meaningfully. The infamous part of d-bus, that it helps inject arbitrary binary payloads into existing text protocols, is now reversed in varlink, it takes what should be arbitrary binary payloads (user records, certificates, etc..) and instead forces you to manage them as JSON objects. Signing and conveying signatures for this object are predictably painful. "The signature section contains one or more cryptographic signatures of a reduced version of the user record. This is used to ensure that only user records defined by a specific source are accepted on a system, by validating the signature against the set of locally accepted signature public keys. The signature is calculated from the JSON user record with all sections removed, except for regular, privileged, perMachine. Specifically, binding, status, signature itself and secret are removed first and thus not covered by the signature. This section is optional, and is only used when cryptographic validation of user records is required (as it is by systemd-homed.service for example)." This all seems very brittle and I don't see the kinds of testing that would project confidence in this system. Good luck to all who use this and trust it.

surajrmal 1y ago
Ultimately ipc, service discovery, and security all need to be codesigned to work together. Systemd is unfortunately trying to work in an ecosystem where it does not have the luxury of a clean first principles approach. Generally I would argue moving off of dbus and onto varlink is in the right direction. I'm not sure what you think is brittle about the approach of using ipc and a schema for the data sent over it. If they had gone in the other direction and mandated grpc ala http instead, would that have been "less brittle"?
- amluto 1y ago
  That IMO does not, in any respect, excuse the signature design. This JSON+blobs design is totally new other than needing to support a handful of preexisting fields. And it’s very much the case that a lot of the record is trusted in the sense that loading malicious data could compromise the integrity or availability of the machine. So structure it like that! Have a whole file that is signed or otherwise integrity-checked in its entirely. Have another file with fields that are per-(user,machine) and integrity-check that. “Integrity-check” means that you validate the binary contents of the file before you even attempt to parse it, and then you parse the literal bytes that you checked. It’s not the nineties anymore, and architects should know better.

aryonoco 1y ago

For those curious about systemd-homed, lwn had a writeup about a discussion in Fedora about it which provides a good summary of the pros and cons of systemd-homed. https://lwn.net/Articles/995915/ https://lwn.net/Articles/995915/

throw0101d 1y ago

It seems to be that a lot of what systemd is doing (over and above being 'just' an init system) seems to be focused on standalone systems. And that's fine and all for some folks, but for those of us sysadmin-ing servers/VMs, it's all sorts of annoying that these sub-systems exist for dynamic environments (laptops using networkd/resolvd/etc to handle moving around), but I just want my system to be static and not have (e.g.) resolv.conf futzed around with (I've taken to doing a chattr +i on the file quite often).

nixosbestos 1y ago
Hm. So then don't use (systemd-)resolved? Alternatively, I've accepted that it's built to work with a decades-old ecosystem and that resolv.conf is effectively a generated, read-only-except-resolved file. And in turn, resolved's configuration is perfectly static and equally immutable. /shrug My* only problem is that it's pretty good at what it does, and can be... more helpful than you might like at providing consistent global DNS resolution. For example, it's use over dbus makes processes in `netns`s susceptible to leaking DNS requests. Though arguably I should've been going more full-containery than just a netns maybe, given my expectations.
- throw0101a 1y ago
  > Hm. So then don't use (systemd-)resolved? The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable. Changing the IP address was also fairly simple in editing a file, but now there's networkd sometimes, and NetManager other times, and netplan too, and perhaps make sure your YAML file is indented with the right number of spaces in the right place…
  - yjftsjthsd-h 1y ago
    > The number of ways and things that twiddle with /etc/resolv.conf nowadays is quite unreasonable. In many years of daily-driving unix-likes and being an amateur and professional sysadmin, I think resolv.conf is the only time I've ever actually used `chattr +i`.
1y ago

erlkonig 1y ago

<tirade style="justified"> F*k systemd, and systemd-homed along with it. Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn. Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight. Looking through the doc at https://systemd.io/HOME_DIRECTORY/ https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems. I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash. </tirade>