7 ms·

I read the design document for this. What's the point? This is not the 1990s. Who exactly is this for? Who actually has multi-user systems. Really has them.

I read the design document for this. What's the point? This is not the 1990s. Who exactly is this for? Who actually has multi-user systems. Really has them. Clients are either all single-user laptops (at home and at work), or single-user workstations. Very rarely they're multi user workstations, but then they use something non-local for their home directories anyway, so again who is this for? This isn't the 1990s with 100 users on your computer club Linux server. Everyone just gets their own VM, now. Honestly, who still runs a 1990s style shared shell server? And per-user /home encryption on a shared system just sounds like a threat model contradiction. If you want to protect the users from each other then turning a blind eye to the regular local root exploits sounds odd at best. On servers for cifs /home if my home directory is secret, why would I expose it to every server I log in to? And if not for human user accounts, how will this help anyone run their docker containers or any other type of service? Am I just out of touch? Does this actually have users? Does it actually solve a problem? It breaks many use cases, that's very obvious.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
Iolaum 7y ago
Anecdotally, my laptop is being used by two users. It irks very much that neither Ubuntu nor Fedora can easily support a common directory for data to be shared between users. I ve created custom bash commands to fix group file ownership and similar issues arising from sharing a directory between two home users.
- grosswait 7y ago
  Have you looked into ACLs and/or setgid with a shared group? Used to do this at work all the time for numerous groups of users. This is definitely possible. You may need to pay attention to your umask.
  - Iolaum 7y ago
    I have not looked at ACLs. They look too complex. Setgid works on file copy but not on file move. Not sure about umask.
    - beagle3 7y ago
      Well, move on ext4 (and most other Linux filesystems) has very specific semantics - keep the file intact in every possible way (including permissions, modification time, ownership etc) but make it visible through another name. Please be aware that that the common semantics are that permissions are associated with a file, not with its name (and a file may have a lot of names through hard links, or no name at all - open a file, delete it, and it is only accessible if you have an fd, or with little more work through the inode number)
      - Iolaum 7y ago
        I am indeed on ext4 (and MATE DE). Thank you for the information, although I am not sure what's the next step to have the OS enforce a certain group (and 775 permissions optimally) on all files created/copied/moved (moved is the part that's the biggest pain) within a certain directory.
        beagle3 7y ago
        You can write a script that does "inotify_wait" on your directory and changes the permission on anything that's there and doesn't have them.
        em-bee 7y ago
        a share command that does the necessary permission changes (and optionally the move) would be nice. effectively you want to be able to say: share this file with joe, or share -rw joe john ... file ... destination/; something along those lines that will change the acl as needed.
    - fuzzfactor 7y ago
- shrubble 7y ago
  It should be easy to do this? Create a group, place the two users in that group, create a directory and setgid it to the group.
  - Iolaum 7y ago
    That works when copying but not when moving files. For the latter case you need to manually edit those properties.
- aruggirello 7y ago
  Just setup a third user ("adduser [--disabled-login] user3", then share his home directory: make both users members of the third user's main group "adduser user1 user3 && adduser user2 user3" (assuming you don't want to alter both user's main groups for privacy), then "chmod g+wx /home/user3" and have a cron job enforcing all files in the shared directory belong to the user3 user/group and are writable by the group "* * * * * root chown -r user3:user3 /home/user3 [possibly add: && false || chmod -r g+w /home/user3]". Then create (soft|hard) links to the third user's home dir if you like. This way you retain each user's privacy, since main groups aren't changed, don't need to run custom scripts each time, and don't have multiple copies of the shared files. The only (IMHO minor) issue would be that newly shared files might only be accessible for the other user 30s later on average, and 1 minute at most. The cron job might be converted into a daemon monitoring new files appearing in /home/user3, but that is left as an exercise for the reader :)
- matja 7y ago
  You don't need to use groups since ACLs: setfacl -R \ -m d:u:user1:rwx -m u:user1:rwx \ -m d:u:user2:rwx -m u:user2:rwx \ /home/shared d:u: sets the default user ACL for future directory entries u: sets the current user ACL for existing directory entries -R sets the ACLs recursively on existing files
grosswait 7y ago
I'm not a systemd fan by any means, but yes, there are far more ways Linux is used where this will be useful. There are still compute clusters and terminal servers where the overhead and isolation of a VM is counterproductive, and use cases where containers are not yet secure enough. I also think it's likely there are future solutions which will be made possible that we can't even imagine right now, through what this brings to the table.
- knorker 7y ago
  But in these clusters where a VM is too much overhead, isn't LUKS and the others? I manage huge compute clusters, with and without VMs, and can't imagine a feasible use case for this, barring a time machine to the 90s.
  - rumanator 7y ago
    > But in these clusters where a VM is too much overhead, isn't LUKS and the others? No. First of all, in general disk encryption is orthogonal to multi-user or multi-seat systems, and the same case for disk encryption can be made wrt VM sessions. Secondly, the main feature is migratable and self-contained home directories, which is also relevant for VMs (or even more relevant).
    - knorker 7y ago
      Hmm... migratable and self-contained home directories. What do you mean? iSCSI, or something like it? Again, I'm not seeing what value systemd is adding here.
m4rtink 7y ago
Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous as it's Android) implementation. Still, the main aim of this is in my opinion not safe isolation of users on a single machine, but rather safe locking of the encrypted root folder. With a normal LUKS setup, everything is inside a LUKS container, including the rootfs from which the OS itself is running. This complicates locking the LUKS container when the device gets suspended, as there will be open files, etc. With Homed as far as I can tell, this is explicitly possible, it should be able to drop the encryption keys when machine goes to suspend, making it less likely your data will be recovered if the machine gets lost or stolen. With the keys in RAM an attacker might attempt to pull it from the machine & read the keys or use some method to defeat the lockscreen. With the keys dumped from RAM, this is no longer possible.
- knorker 7y ago
  Android is so hugely different that it's not really an argument for adding it to systemd. > [locking when suspenden] With Homed as far as I can tell, this is explicitly possible Is it? Your home dir definitely will have open files when you lock or suspend.
- michaelmrose 7y ago
  > The go-luks-suspend program replaces the default suspend mechanism of systemd. It chroots to initramfs in order to perform the luksSuspend, suspend to RAM, and luksResume operations. It relies on the shutdown initcpio hook to provide access to the initramfs. https://github.com/guns/go-luks-suspend https://github.com/guns/go-luks-suspend from 2013 This also doesn't accidentally leak all the stuff not within /home/you
horsawlarway 7y ago
They're rampant in the education industry - At basically every level. School labs with many shared computers for kids high school aged and below. Larger servers at colleges for projects that are just unreasonable to run on a standard desktop machine.
- knorker 7y ago
  I'm out of date here, but in my days this was often AFS and stuff. But again: What's the threat model for LUKS, here? A student has their stuff on that exact shared machine in the computer lab, and somehow local root attacks only work when attacker is alone on the machine?
rumanator 7y ago
> Who actually has multi-user systems. Really has them. In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense? Speaking for myself, if multiseat Linux boxes were more easy to setup, I would certainly use one of those as my family's primary desktop. Today's desktop systems are quite capable of taking a multi-user computational beating and breeze through any amount of browser windows opened. Thus, if buying a monitor and keyboard is all it takes to get another computer seat then why not?
- Koshkin 7y ago
  > a monitor and keyboard And a Raspberry Pi.
  - undersuit 7y ago
    Nope, you plug multiple monitors and peripherals into the multiseat box. Terminal(emulator)s are only used over long distances.
  - rumanator 7y ago
    Plugging in an underpowered and resource-starved raspberry pi doesn't give you the same user experience as plugging in a Ryzen7 with 32GB of RAM that you already paid for and have lying around and idling at 5%
    - Koshkin 7y ago
      I guess people have different ideas about what a thin terminal means.
      - rumanator 7y ago
        You're the one confusing a thin terminal with a multi-seat system. This thread is discussing multi-user and multi-seat systems and thin clients is a whole different beast.
mhdhn 7y ago
Use all the time for hobby website. It’s through Pair.com. BSD though, not Linux. It’s very inexpensive and a lot cheaper and easier than me setting up and maintaining a whole virtual box.
brmgb 7y ago
Plenty of places still have homes on NFS shared amongst all their machines. It is very handy. It means you can use any computers and still have all your files. The fact that you are unfamiliar with a use case doesn't mean it doesn't exist.
- knorker 7y ago
  > Plenty of places still have homes on NFS shared amongst all their machines. Oh, I agree! That's my point. So what is systemd trying to solve?
throwaway3neu94 7y ago
Bay area large (not huge) corp dev here. We do. We have like a dozen shared, beefy shell servers (varies, but think ~32 core not too old Xeon, ~256GB RAM, 1G or 10G stable network that's local to the office, TB's of storage and essentially unlimited on NFS) for devs (and more of the same dedicated for CI/CD). We need this because the codebases are huge and take hours to build on a laptop (and copying across a home uplink would take forever too). Homedirs are NFS mounted. It's more cost efficient than spinning up an AWS/Azure instance for myself, and more limited resource efficient than spinning up a VM in OpenStack (both of which I do when appropriate). And it's very convenient team work wise. There are (many, some avoidable but hard to fix by now) downsides for sure, but I cannot imagine doing this work solely on a laptop.
- knorker 7y ago
  At least one huge Bay Area elephant used to run NFS home dirs for basically all their corp. So do you run fscrypt or LUKS with that? Because NFS was already possible, so what is systemd trying to solve?
m463 7y ago
encrypted home directories?
- knorker 7y ago
  Is that a question? I think you missed the point on this one.
  - m463 7y ago
    > > Does it actually solve a problem? > encrypted home directories? This is something that isn't widely available on personal systems that would be supported by this change. I should note I think the idea of systemd is valid, but I am not a fan of the implementation. (binary log files? disorganized configuration directories?)
    - knorker 7y ago
      All my workstations/laptops (at home and at work) have encrypted root filesystem, which includes /home. So… this has not been a problem for 99%+ of users for like 20 years. I do like the idea of some parts of systemd. Like structured logging. I'm so sick of every single tool having its own logging format. Some multi line, some not. Some using UTC, some not. Some making up their own BS date format, etc…
gnfurlong 7y ago
One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation. Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.
- michaelmrose 7y ago
  Full disk encryption is the only reasonable solution and it already works with suspend
saint_abroad 7y ago
> Who actually has multi-user systems. Really has them. systemd-homed isn't about multi-user systems, it's about multi-system users. Goal #1: Migratable Home Directories (all the way to the point of "home-on-a-stick") https://cfp.all-systems-go.io/media/homed-asg2019.pdf https://cfp.all-systems-go.io/media/homed-asg2019.pdf I want to take my home with me across all my systems, and /don't/ want network sync to do it with.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

Iolaum 7y ago

Anecdotally, my laptop is being used by two users. It irks very much that neither Ubuntu nor Fedora can easily support a common directory for data to be shared between users. I ve created custom bash commands to fix group file ownership and similar issues arising from sharing a directory between two home users.

grosswait 7y ago
Have you looked into ACLs and/or setgid with a shared group? Used to do this at work all the time for numerous groups of users. This is definitely possible. You may need to pay attention to your umask.
- Iolaum 7y ago
  I have not looked at ACLs. They look too complex. Setgid works on file copy but not on file move. Not sure about umask.
  - beagle3 7y ago
    Well, move on ext4 (and most other Linux filesystems) has very specific semantics - keep the file intact in every possible way (including permissions, modification time, ownership etc) but make it visible through another name. Please be aware that that the common semantics are that permissions are associated with a file, not with its name (and a file may have a lot of names through hard links, or no name at all - open a file, delete it, and it is only accessible if you have an fd, or with little more work through the inode number)
    - Iolaum 7y ago
      I am indeed on ext4 (and MATE DE). Thank you for the information, although I am not sure what's the next step to have the OS enforce a certain group (and 775 permissions optimally) on all files created/copied/moved (moved is the part that's the biggest pain) within a certain directory.
      - beagle3 7y ago
        You can write a script that does "inotify_wait" on your directory and changes the permission on anything that's there and doesn't have them.
        em-bee 7y ago
        a share command that does the necessary permission changes (and optionally the move) would be nice. effectively you want to be able to say: share this file with joe, or share -rw joe john ... file ... destination/; something along those lines that will change the acl as needed.
  - fuzzfactor 7y ago
shrubble 7y ago
It should be easy to do this? Create a group, place the two users in that group, create a directory and setgid it to the group.
- Iolaum 7y ago
  That works when copying but not when moving files. For the latter case you need to manually edit those properties.
aruggirello 7y ago
Just setup a third user ("adduser [--disabled-login] user3", then share his home directory: make both users members of the third user's main group "adduser user1 user3 && adduser user2 user3" (assuming you don't want to alter both user's main groups for privacy), then "chmod g+wx /home/user3" and have a cron job enforcing all files in the shared directory belong to the user3 user/group and are writable by the group "* * * * * root chown -r user3:user3 /home/user3 [possibly add: && false || chmod -r g+w /home/user3]". Then create (soft|hard) links to the third user's home dir if you like. This way you retain each user's privacy, since main groups aren't changed, don't need to run custom scripts each time, and don't have multiple copies of the shared files. The only (IMHO minor) issue would be that newly shared files might only be accessible for the other user 30s later on average, and 1 minute at most. The cron job might be converted into a daemon monitoring new files appearing in /home/user3, but that is left as an exercise for the reader :)
matja 7y ago
You don't need to use groups since ACLs: setfacl -R \ -m d:u:user1:rwx -m u:user1:rwx \ -m d:u:user2:rwx -m u:user2:rwx \ /home/shared d:u: sets the default user ACL for future directory entries u: sets the current user ACL for existing directory entries -R sets the ACLs recursively on existing files

grosswait 7y ago

I'm not a systemd fan by any means, but yes, there are far more ways Linux is used where this will be useful. There are still compute clusters and terminal servers where the overhead and isolation of a VM is counterproductive, and use cases where containers are not yet secure enough. I also think it's likely there are future solutions which will be made possible that we can't even imagine right now, through what this brings to the table.

knorker 7y ago
But in these clusters where a VM is too much overhead, isn't LUKS and the others? I manage huge compute clusters, with and without VMs, and can't imagine a feasible use case for this, barring a time machine to the 90s.
- rumanator 7y ago
  > But in these clusters where a VM is too much overhead, isn't LUKS and the others? No. First of all, in general disk encryption is orthogonal to multi-user or multi-seat systems, and the same case for disk encryption can be made wrt VM sessions. Secondly, the main feature is migratable and self-contained home directories, which is also relevant for VMs (or even more relevant).
  - knorker 7y ago
    Hmm... migratable and self-contained home directories. What do you mean? iSCSI, or something like it? Again, I'm not seeing what value systemd is adding here.

m4rtink 7y ago

Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous as it's Android) implementation. Still, the main aim of this is in my opinion not safe isolation of users on a single machine, but rather safe locking of the encrypted root folder. With a normal LUKS setup, everything is inside a LUKS container, including the rootfs from which the OS itself is running. This complicates locking the LUKS container when the device gets suspended, as there will be open files, etc. With Homed as far as I can tell, this is explicitly possible, it should be able to drop the encryption keys when machine goes to suspend, making it less likely your data will be recovered if the machine gets lost or stolen. With the keys in RAM an attacker might attempt to pull it from the machine & read the keys or use some method to defeat the lockscreen. With the keys dumped from RAM, this is no longer possible.

knorker 7y ago
Android is so hugely different that it's not really an argument for adding it to systemd. > [locking when suspenden] With Homed as far as I can tell, this is explicitly possible Is it? Your home dir definitely will have open files when you lock or suspend.
michaelmrose 7y ago
> The go-luks-suspend program replaces the default suspend mechanism of systemd. It chroots to initramfs in order to perform the luksSuspend, suspend to RAM, and luksResume operations. It relies on the shutdown initcpio hook to provide access to the initramfs. https://github.com/guns/go-luks-suspend https://github.com/guns/go-luks-suspend from 2013 This also doesn't accidentally leak all the stuff not within /home/you

horsawlarway 7y ago

They're rampant in the education industry - At basically every level. School labs with many shared computers for kids high school aged and below. Larger servers at colleges for projects that are just unreasonable to run on a standard desktop machine.

knorker 7y ago
I'm out of date here, but in my days this was often AFS and stuff. But again: What's the threat model for LUKS, here? A student has their stuff on that exact shared machine in the computer lab, and somehow local root attacks only work when attacker is alone on the machine?

rumanator 7y ago

> Who actually has multi-user systems. Really has them. In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense? Speaking for myself, if multiseat Linux boxes were more easy to setup, I would certainly use one of those as my family's primary desktop. Today's desktop systems are quite capable of taking a multi-user computational beating and breeze through any amount of browser windows opened. Thus, if buying a monitor and keyboard is all it takes to get another computer seat then why not?

Koshkin 7y ago
> a monitor and keyboard And a Raspberry Pi.
- undersuit 7y ago
  Nope, you plug multiple monitors and peripherals into the multiseat box. Terminal(emulator)s are only used over long distances.
- rumanator 7y ago
  Plugging in an underpowered and resource-starved raspberry pi doesn't give you the same user experience as plugging in a Ryzen7 with 32GB of RAM that you already paid for and have lying around and idling at 5%
  - Koshkin 7y ago
    I guess people have different ideas about what a thin terminal means.
    - rumanator 7y ago
      You're the one confusing a thin terminal with a multi-seat system. This thread is discussing multi-user and multi-seat systems and thin clients is a whole different beast.

mhdhn 7y ago

Use all the time for hobby website. It’s through Pair.com. BSD though, not Linux. It’s very inexpensive and a lot cheaper and easier than me setting up and maintaining a whole virtual box.

brmgb 7y ago

Plenty of places still have homes on NFS shared amongst all their machines. It is very handy. It means you can use any computers and still have all your files. The fact that you are unfamiliar with a use case doesn't mean it doesn't exist.

knorker 7y ago
> Plenty of places still have homes on NFS shared amongst all their machines. Oh, I agree! That's my point. So what is systemd trying to solve?

throwaway3neu94 7y ago

Bay area large (not huge) corp dev here. We do. We have like a dozen shared, beefy shell servers (varies, but think ~32 core not too old Xeon, ~256GB RAM, 1G or 10G stable network that's local to the office, TB's of storage and essentially unlimited on NFS) for devs (and more of the same dedicated for CI/CD). We need this because the codebases are huge and take hours to build on a laptop (and copying across a home uplink would take forever too). Homedirs are NFS mounted. It's more cost efficient than spinning up an AWS/Azure instance for myself, and more limited resource efficient than spinning up a VM in OpenStack (both of which I do when appropriate). And it's very convenient team work wise. There are (many, some avoidable but hard to fix by now) downsides for sure, but I cannot imagine doing this work solely on a laptop.

knorker 7y ago
At least one huge Bay Area elephant used to run NFS home dirs for basically all their corp. So do you run fscrypt or LUKS with that? Because NFS was already possible, so what is systemd trying to solve?

m463 7y ago

encrypted home directories?

knorker 7y ago
Is that a question? I think you missed the point on this one.
- m463 7y ago
  > > Does it actually solve a problem? > encrypted home directories? This is something that isn't widely available on personal systems that would be supported by this change. I should note I think the idea of systemd is valid, but I am not a fan of the implementation. (binary log files? disorganized configuration directories?)
  - knorker 7y ago
    All my workstations/laptops (at home and at work) have encrypted root filesystem, which includes /home. So… this has not been a problem for 99%+ of users for like 20 years. I do like the idea of some parts of systemd. Like structured logging. I'm so sick of every single tool having its own logging format. Some multi line, some not. Some using UTC, some not. Some making up their own BS date format, etc…

gnfurlong 7y ago

One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation. Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.

michaelmrose 7y ago
Full disk encryption is the only reasonable solution and it already works with suspend

saint_abroad 7y ago

> Who actually has multi-user systems. Really has them. systemd-homed isn't about multi-user systems, it's about multi-system users. Goal #1: Migratable Home Directories (all the way to the point of "home-on-a-stick") https://cfp.all-systems-go.io/media/homed-asg2019.pdf https://cfp.all-systems-go.io/media/homed-asg2019.pdf I want to take my home with me across all my systems, and /don't/ want network sync to do it with.