11 ms·

Systemd-Homed: Systemd Now Working to Improve Home Directory Handling

66 points by protomyth 7y ago

CameronNemo 7y ago
There was a recent /r/linux thread regarding this.(https://reddit.com/comments/d6w03y https://reddit.com/comments/d6w03y) Lennart responds to some questions people had.
- trynewideas 7y ago
  > User records are not frequently updated and are not typically updated by multiple players simultaneously. Would love to see what Lennart measured and how he came to this conclusion.
  - wademealing 7y ago
    Is this difficult to believe, do you delete users hundreds of times a day ?
    - CameronNemo 7y ago
      Well he is 'reinventing' home directories as an independent concept. This storage artifact could be updated frequently and over the network. The concern may be insignifcant until this homed feature has its limits stretched.
      - theamk 7y ago
        That quote s about user record - full name, password, expirations, limits etc.. how often do you change this? It does not apply to user files, there is a completely different mechanism for them
    - trynewideas 7y ago
      I don't on my personal laptop, but my workplace's wacky automation does on my work laptop, and school and library automation definitely does on shared workstations, including laptops. I get that that's the problem of the automation, not the daemon, but I'm curious about who exactly is representing users when the people running a project state things like that so unequivocally, and if those users are just excluded from any benefits from a system like this because fuck 'em.
  - nightfly 7y ago
    In cases where they are, you're probably using a central account management system like ldap anyway.
  - theamk 7y ago
    Given that the whole system is targeted for laptops, this seems somewhat obvious and does not seem to be something you need to measure? The worst thing I can think of is classroom environment - and even that would be at most 1 update per hour, which is pretty infrequent in the context (the update frequency needs to be much bigger than the clock skew, which is normally under a second) And even that assumes that each record is updated every time user logs in (since each record is stored separately). In practice, records could be added or removed to the system, but the actual modification will be pretty rare - once initial setup is done, it will be only periodic password changes.
  - poettering 7y ago
    Well. How frequently do you update your user record in /etc/passwd? I mean, if you do this a million times per second then maybe your are doig something wrong, no? I update my user record maybe every year when I update my password, but if you do that once per ms then uh oh
deleted 7y ago
[deleted]
m45t3r 7y ago
Reading the slides this seems really interesting. A way to allow you simple copy your home (that may be in an encrypted loop file) to a Pendrive and have all your configuration anywhere seems like a big win. This will make the only stateful thing in my system (my home directory) much easier to backup and move. Also the death of /etc/shadow and /etc/passwd (state in a directory that should only contain configuration files). And encrypted home on suspend. Like most systemd things, this should be completely optional. Also like most systemd things, people will complain that this is unnecessary bloat.
- fhennig 7y ago
  It is completly optional, also it is optional to use home encryption (this comes up a lot when people want to log in on a remote server with a user that uses homed). homed users and conventional users can exist side by side.
  - sverige 7y ago
    Funny, that's what I heard when systemd was introduced: "it's completely optional." And yet today I don't think I would use both hands counting the Linux distros without systemd, though far more than that number tried and finally gave up.
    - eropple 7y ago
      I'm sure they all gave up because of politics, too, and not because systemd gets way more right than it gets wrong despite a vocal minority of noncontributory angst.
      - sverige 7y ago
        Unfortunately, it will probably take ten years to see the real effects of these decisions on the ecosystem. I hope you're right that this is the way to go, but I fear I'll be right that Linux will be at least as opaque as Windows to anyone who wants an entry point into learning about operating systems and systems administration without having to pay to take classes.
amos19870630 7y ago
This actually looks like a really interesting idea, though I'm curious to see how well it'd handle the combination of both local and shared storage.
drjesusphd 7y ago
So this is how systemd takes over the Linux file system?
deleted 7y ago
[deleted]
kylek 7y ago
(Incoming downvotes. Sorry I can't contain myself. Yes, it's sarcasm and I hate that I feel like I have to preface this) >>> improve intransitive verb To raise to a more desirable or more excellent quality or condition; make better. intransitive verb To increase the productivity or value of (land or property). intransitive verb To become better. >>> Either we need a new definition, or start calling it GNU/systemd edit: What I'm actually trying to get at is- "are all distros that implement systemd expected to jump on every major architectural change that Lennart&co come up with?" Is this not asking a lot? That's a ton of weight and a lot decisions that have been traditionally owned by the distros. Maybe nobody actually wants to think about this stuff, though.
- bitwize 7y ago
  > What I'm actually trying to get at is- "are all distros that implement systemd expected to jump on every major architectural change that Lennart&co come up with?" Yes. > Is this not asking a lot? It isn't. Especially since Lennart & co. have done most of the hard work. > That's a ton of weight and a lot decisions that have been traditionally owned by the distros. That's kind of the point. The goal of systemd is to provide a single, unified, comprehensive Linux platform and undo some of the fragmentation that has occurred in the Linux space between distributions. For example, systemd service files work the same irrespective of distro. Upstream developers need supply only one service file that can then be used on all distros.
  - kylek 7y ago
    >> That's kind of the point. The goal of systemd is to provide a single, unified, comprehensive Linux platform and undo some of the fragmentation that has occurred in the Linux space between distributions. Huh I guess I hadn't thought of it that way. I've always viewed the "fragmentation" (opinionated differences giving the end-user more choice) between distros as a feature, not a bug. I don't know, I still feel the "systemd or not" choice still comes off a bit ham-handed. But maybe it doesn't matter anymore (considering that all old/big distros that wanted to implement it probably already have, and any new one is free to use it or not). Probably also has to do with the barrier-to-entry of using Linux being far lower than it used to be (maybe in part due to systemd?)
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
lawnchair_larry 7y ago
I think we need less dependence on systemd, not more. It’s already a mess.
- scrollaway 7y ago
  I'd like to see you construct an actual reasonable argument that it's a mess, that isn't based on hearsay or just "I liked it better the old way".
andrerm 7y ago
> So do I understand it correctly? The solution to SSH remote login is to not have it? > With systemd-homed access to the home directory is simply impossible unless the luks keyphrase (aka "user password") is specified (i.e. tje user logged in) since the data store is after all fully encrypted unless the user logs in. Thats a good thing btw: the user's data should be protected from the system unless the user is actually logged in. Now, ssh public key auth doesnt deal with passwords hence just using ssh pk auth means we couldnt unlock the luks volume simply because we have no keyphrase to unlock things with. So the PAM module that unlocks homed volumes actually enquires the client for the password explicitly if this happens. Unfortunately this is not sufficient for this to work with openssh since its pam hook-up doesnt support asking questions via pam after authentication. > That said people suggested we maybe should provide a stub account you can log into with a fixed password that instead of a shell just spawns a program that queries you for username and password and then allows you to unlock the specified home directory. I get that GNU is not Unix but why do this guy hates Unix so much?
- tyingq 7y ago
  Wouldn't it similarly have issues with the various desktop UI logins? Or do these all use systemd-logind?
  - bitwize 7y ago
    The ones that don't use systemd-logind can be safely ignored because they aren't modern, or compatible with the modern Linux ecosystem.
  - eikenberry 7y ago
    The quoted paragraph says it uses a PAM module to unlock it, and PAM is independent of systemd.
- eikenberry 7y ago
  My guess is that this is not meant for systems you'd ssh into. That this particular feature is designed specifically for use on laptops.
deleted 7y ago
[deleted]
darren0 7y ago
Systemd has always been hyper focused on the desktop/laptop experience, and then justified for other use cases. Desktop is by a rediculously huge margin the least important use case. So something like systemd-homed does not make any sense in a server setup but I can basically guarantee it will be forced upon server setups, just like systemd-resolvd was. Ironically the very small percentage of users that use Linux on the desktop tend to be of the more die-hard variety that don't welcome systemd's view of the world. In the end systemd is an extremely bad steward of Linux.
- nightfly 7y ago
  My organization has been very happy with using systemd on servers. Having an init system that can automatically restart failed services, and with decent sdependency management is a big win. We've also been able to replace many 50-100 line long init scripts with systemd unit definitions that are 10 lines long, and considerably more readable than the bash init scripts they replaced. We've had some bad experiences too, logins being "slow" because something went wrong and left 1000s of leftover session units in a weird state, systemd vulnerabilities requiring reboots occasionally. But systemd has had a net-positive impact.
  - cat199 7y ago
    nothing precludes a reasonable shell library from making initscripts 10 lines long: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.6&content-type=text/x-cvsweb-markup&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.... this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
    - CameronNemo 7y ago
      OpenRC is similarly concise. The runit run scripts used on Void Linux are too, but they rarely take into account complicated dependencies so they are fragile.
    - theamk 7y ago
mrtweetyhack 7y ago
haha
Porthos9K 7y ago
All I've got to say is that I'm glad the BSDs make decent workstations even though desktop isn't their primary use case. Because I'm reading this and thinking, "Oh, hell no." I'm reacting like this because I honestly don't get it. Why does systemd need a subsystem that touches /home?
- cat199 7y ago
  > Why does systemd need a subsystem that touches /home? because they haven't written one that touches home yet?
- theamk 7y ago
  It is all described in the first slides, I’d summarize it as “encrypted decentralized roaming profile”. It’s a pretty specialized feature - I’d myself would not want to use it. But I can think of some situations where this can be very handy. And from the practical standpoint, it is not that bad. As far as files access goes, it is compatible with everything, and quering password db will also work. The only thing that changed is how you create interactive users, and it’s not like it was standardized before.
  - Porthos9K 7y ago
    I think I get it now. This is for corporate desktop, not necessarily personal use.
cosmonism 7y ago
I'm confused. Why can't they remote login to a box with their home directory encrypted? Is it not enough to have the pubkey stored outside their home? e.g. # /etc/ssh/sshd_config AuthorizedKeysFile /var/ssh/%u/authorized_keys Once they authenticate they can run cryptsetup or what-have-you. To me that sounds way better than having randos guess your luks passphrase.
- cnvogel 7y ago
  Yes, that's certainly a solution. Or using a certification authority for users (TrustedUserCAKeys in sshd_config), so that any user that has a signed certificate, and owns the corresponding private key, would be allowed to login. No further updates of authroized_keys files needed. And, to further automate the ssh login, maybe your LUKS container could have a second (Nth) key-slot being a random key RSA-encrypted with the other machine's identity private key? (https://bjornjohansen.no/encrypt-file-using-ssh-key https://bjornjohansen.no/encrypt-file-using-ssh-key for examples) But generally, I really dislike the use of LUKS in this case, as I think a filesystem based encryption (not encrypting whole block devices) would make more sense. I understand that this isn't as mature as LUKS, though.
- poettering 7y ago
  We actually use something like the above. But thats not sufficient since we cannot set up the PAM session fully if $HOME is not accessible because we can't acquire a password for it...
mappu 7y ago
There's a problem with loading the home directory as a loopback block device from roaming USB disks - untrusted filesystems aren't safe to mount. From https://lwn.net/Articles/755593/ https://lwn.net/Articles/755593/ "Unprivileged filesystem mounts, 2018 edition": > There's little we can do to prevent people from exploiting flaws in the filesystem's on-disk format. No filesystem has robust, exhaustive verification of all it's metadata, nor is that something we can really check at runtime due to the complexity and overhead of runtime checking. [...] "Go run your filesystem in userspace with fuse if you want stronger security guarantees." But the same topic is also discussed in many similar articles, e.g. more recently regarding the likeliness of opening new bugs for everyone using automount since the new EROFS filesystem has been merged into the mainline kernel.
- poettering 7y ago
  Yes this is a problem. To address this systemd-homed is careful to validate the user record enclosed in the volume first (which includes checking its signature against the keyring of accepted record signers) and checks whether the provided user password can unlock it. Only after this validation and that the fs actually matches the record we will mount it. Thus as long as the employer trusts its employees enough things should be reasonably safe. (To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs)
  - Mrat 7y ago
    Hi, Lennart. My question isn't related to what you were answering in this comment but it's related to some problems I have to deal since I'm constantly moving my /home folder from a distribution to another. I always have to delete files like ~/.local/share/applications/.desktop because otherwise it will show stuff that shouldn't be available in a freshly-installed distribution and it makes me think it's "contaminated"*. I wanted to know how this new implementation deals with those cases. BTW, congratulations! You made a systemd "hater" like me agree with you. I would be really grateful if this solution made me forget about cleaning up my home before a new install. Have a nice day!
sifar 7y ago
May be this is a naive question, but it talks about making home directories portable. In that case how does it resolve when two different users on two different machines with the same username try to move it to the same stick ? How does it guarantee unique UIDs across different machines ?
waste_monk 7y ago
Cancer now working to improve brain tissue handling.
AstralStorm 7y ago
So instead of writing a PAM module like normal people... Wait, it already exists. pam_mount, used to typically mount ecryptfs. Welcome to NIH.
- poettering 7y ago
  Uh oh. This is implemented via a PAM module too. But it does substantially more than pam_mount so not sure what you want. It's like claiming that UNIX 'find' is NIH because 'ls' already can show directory listings.

66 points by protomyth 7y ago

There was a recent /r/linux thread regarding this.(https://reddit.com/comments/d6w03y https://reddit.com/comments/d6w03y) Lennart responds to some questions people had.

trynewideas 7y ago
> User records are not frequently updated and are not typically updated by multiple players simultaneously. Would love to see what Lennart measured and how he came to this conclusion.
- wademealing 7y ago
  Is this difficult to believe, do you delete users hundreds of times a day ?
  - CameronNemo 7y ago
    Well he is 'reinventing' home directories as an independent concept. This storage artifact could be updated frequently and over the network. The concern may be insignifcant until this homed feature has its limits stretched.
    - theamk 7y ago
      That quote s about user record - full name, password, expirations, limits etc.. how often do you change this? It does not apply to user files, there is a completely different mechanism for them
  - trynewideas 7y ago
    I don't on my personal laptop, but my workplace's wacky automation does on my work laptop, and school and library automation definitely does on shared workstations, including laptops. I get that that's the problem of the automation, not the daemon, but I'm curious about who exactly is representing users when the people running a project state things like that so unequivocally, and if those users are just excluded from any benefits from a system like this because fuck 'em.
- nightfly 7y ago
  In cases where they are, you're probably using a central account management system like ldap anyway.
- theamk 7y ago
  Given that the whole system is targeted for laptops, this seems somewhat obvious and does not seem to be something you need to measure? The worst thing I can think of is classroom environment - and even that would be at most 1 update per hour, which is pretty infrequent in the context (the update frequency needs to be much bigger than the clock skew, which is normally under a second) And even that assumes that each record is updated every time user logs in (since each record is stored separately). In practice, records could be added or removed to the system, but the actual modification will be pretty rare - once initial setup is done, it will be only periodic password changes.
- poettering 7y ago
  Well. How frequently do you update your user record in /etc/passwd? I mean, if you do this a million times per second then maybe your are doig something wrong, no? I update my user record maybe every year when I update my password, but if you do that once per ms then uh oh

deleted 7y ago

[deleted]

m45t3r 7y ago

Reading the slides this seems really interesting. A way to allow you simple copy your home (that may be in an encrypted loop file) to a Pendrive and have all your configuration anywhere seems like a big win. This will make the only stateful thing in my system (my home directory) much easier to backup and move. Also the death of /etc/shadow and /etc/passwd (state in a directory that should only contain configuration files). And encrypted home on suspend. Like most systemd things, this should be completely optional. Also like most systemd things, people will complain that this is unnecessary bloat.

fhennig 7y ago
It is completly optional, also it is optional to use home encryption (this comes up a lot when people want to log in on a remote server with a user that uses homed). homed users and conventional users can exist side by side.
- sverige 7y ago
  Funny, that's what I heard when systemd was introduced: "it's completely optional." And yet today I don't think I would use both hands counting the Linux distros without systemd, though far more than that number tried and finally gave up.
  - eropple 7y ago
    I'm sure they all gave up because of politics, too, and not because systemd gets way more right than it gets wrong despite a vocal minority of noncontributory angst.
    - sverige 7y ago
      Unfortunately, it will probably take ten years to see the real effects of these decisions on the ecosystem. I hope you're right that this is the way to go, but I fear I'll be right that Linux will be at least as opaque as Windows to anyone who wants an entry point into learning about operating systems and systems administration without having to pay to take classes.

amos19870630 7y ago

This actually looks like a really interesting idea, though I'm curious to see how well it'd handle the combination of both local and shared storage.

drjesusphd 7y ago

So this is how systemd takes over the Linux file system?

deleted 7y ago

[deleted]

kylek 7y ago

(Incoming downvotes. Sorry I can't contain myself. Yes, it's sarcasm and I hate that I feel like I have to preface this) >>> improve intransitive verb To raise to a more desirable or more excellent quality or condition; make better. intransitive verb To increase the productivity or value of (land or property). intransitive verb To become better. >>> Either we need a new definition, or start calling it GNU/systemd edit: What I'm actually trying to get at is- "are all distros that implement systemd expected to jump on every major architectural change that Lennart&co come up with?" Is this not asking a lot? That's a ton of weight and a lot decisions that have been traditionally owned by the distros. Maybe nobody actually wants to think about this stuff, though.

bitwize 7y ago
> What I'm actually trying to get at is- "are all distros that implement systemd expected to jump on every major architectural change that Lennart&co come up with?" Yes. > Is this not asking a lot? It isn't. Especially since Lennart & co. have done most of the hard work. > That's a ton of weight and a lot decisions that have been traditionally owned by the distros. That's kind of the point. The goal of systemd is to provide a single, unified, comprehensive Linux platform and undo some of the fragmentation that has occurred in the Linux space between distributions. For example, systemd service files work the same irrespective of distro. Upstream developers need supply only one service file that can then be used on all distros.
- kylek 7y ago
  >> That's kind of the point. The goal of systemd is to provide a single, unified, comprehensive Linux platform and undo some of the fragmentation that has occurred in the Linux space between distributions. Huh I guess I hadn't thought of it that way. I've always viewed the "fragmentation" (opinionated differences giving the end-user more choice) between distros as a feature, not a bug. I don't know, I still feel the "systemd or not" choice still comes off a bit ham-handed. But maybe it doesn't matter anymore (considering that all old/big distros that wanted to implement it probably already have, and any new one is free to use it or not). Probably also has to do with the barrier-to-entry of using Linux being far lower than it used to be (maybe in part due to systemd?)

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

lawnchair_larry 7y ago

I think we need less dependence on systemd, not more. It’s already a mess.

scrollaway 7y ago
I'd like to see you construct an actual reasonable argument that it's a mess, that isn't based on hearsay or just "I liked it better the old way".

andrerm 7y ago

> So do I understand it correctly? The solution to SSH remote login is to not have it? > With systemd-homed access to the home directory is simply impossible unless the luks keyphrase (aka "user password") is specified (i.e. tje user logged in) since the data store is after all fully encrypted unless the user logs in. Thats a good thing btw: the user's data should be protected from the system unless the user is actually logged in. Now, ssh public key auth doesnt deal with passwords hence just using ssh pk auth means we couldnt unlock the luks volume simply because we have no keyphrase to unlock things with. So the PAM module that unlocks homed volumes actually enquires the client for the password explicitly if this happens. Unfortunately this is not sufficient for this to work with openssh since its pam hook-up doesnt support asking questions via pam after authentication. > That said people suggested we maybe should provide a stub account you can log into with a fixed password that instead of a shell just spawns a program that queries you for username and password and then allows you to unlock the specified home directory. I get that GNU is not Unix but why do this guy hates Unix so much?

tyingq 7y ago
Wouldn't it similarly have issues with the various desktop UI logins? Or do these all use systemd-logind?
- bitwize 7y ago
  The ones that don't use systemd-logind can be safely ignored because they aren't modern, or compatible with the modern Linux ecosystem.
- eikenberry 7y ago
  The quoted paragraph says it uses a PAM module to unlock it, and PAM is independent of systemd.
eikenberry 7y ago
My guess is that this is not meant for systems you'd ssh into. That this particular feature is designed specifically for use on laptops.

deleted 7y ago

[deleted]

darren0 7y ago

Systemd has always been hyper focused on the desktop/laptop experience, and then justified for other use cases. Desktop is by a rediculously huge margin the least important use case. So something like systemd-homed does not make any sense in a server setup but I can basically guarantee it will be forced upon server setups, just like systemd-resolvd was. Ironically the very small percentage of users that use Linux on the desktop tend to be of the more die-hard variety that don't welcome systemd's view of the world. In the end systemd is an extremely bad steward of Linux.

nightfly 7y ago
My organization has been very happy with using systemd on servers. Having an init system that can automatically restart failed services, and with decent sdependency management is a big win. We've also been able to replace many 50-100 line long init scripts with systemd unit definitions that are 10 lines long, and considerably more readable than the bash init scripts they replaced. We've had some bad experiences too, logins being "slow" because something went wrong and left 1000s of leftover session units in a weird state, systemd vulnerabilities requiring reboots occasionally. But systemd has had a net-positive impact.
- cat199 7y ago
  nothing precludes a reasonable shell library from making initscripts 10 lines long: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.6&content-type=text/x-cvsweb-markup&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.... this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
  - CameronNemo 7y ago
    OpenRC is similarly concise. The runit run scripts used on Void Linux are too, but they rarely take into account complicated dependencies so they are fragile.
  - theamk 7y ago

mrtweetyhack 7y ago

haha

Porthos9K 7y ago

All I've got to say is that I'm glad the BSDs make decent workstations even though desktop isn't their primary use case. Because I'm reading this and thinking, "Oh, hell no." I'm reacting like this because I honestly don't get it. Why does systemd need a subsystem that touches /home?

cat199 7y ago
> Why does systemd need a subsystem that touches /home? because they haven't written one that touches home yet?
theamk 7y ago
It is all described in the first slides, I’d summarize it as “encrypted decentralized roaming profile”. It’s a pretty specialized feature - I’d myself would not want to use it. But I can think of some situations where this can be very handy. And from the practical standpoint, it is not that bad. As far as files access goes, it is compatible with everything, and quering password db will also work. The only thing that changed is how you create interactive users, and it’s not like it was standardized before.
- Porthos9K 7y ago
  I think I get it now. This is for corporate desktop, not necessarily personal use.

cosmonism 7y ago

I'm confused. Why can't they remote login to a box with their home directory encrypted? Is it not enough to have the pubkey stored outside their home? e.g. # /etc/ssh/sshd_config AuthorizedKeysFile /var/ssh/%u/authorized_keys Once they authenticate they can run cryptsetup or what-have-you. To me that sounds way better than having randos guess your luks passphrase.

cnvogel 7y ago
Yes, that's certainly a solution. Or using a certification authority for users (TrustedUserCAKeys in sshd_config), so that any user that has a signed certificate, and owns the corresponding private key, would be allowed to login. No further updates of authroized_keys files needed. And, to further automate the ssh login, maybe your LUKS container could have a second (Nth) key-slot being a random key RSA-encrypted with the other machine's identity private key? (https://bjornjohansen.no/encrypt-file-using-ssh-key https://bjornjohansen.no/encrypt-file-using-ssh-key for examples) But generally, I really dislike the use of LUKS in this case, as I think a filesystem based encryption (not encrypting whole block devices) would make more sense. I understand that this isn't as mature as LUKS, though.
poettering 7y ago
We actually use something like the above. But thats not sufficient since we cannot set up the PAM session fully if $HOME is not accessible because we can't acquire a password for it...

mappu 7y ago

There's a problem with loading the home directory as a loopback block device from roaming USB disks - untrusted filesystems aren't safe to mount. From https://lwn.net/Articles/755593/ https://lwn.net/Articles/755593/ "Unprivileged filesystem mounts, 2018 edition": > There's little we can do to prevent people from exploiting flaws in the filesystem's on-disk format. No filesystem has robust, exhaustive verification of all it's metadata, nor is that something we can really check at runtime due to the complexity and overhead of runtime checking. [...] "Go run your filesystem in userspace with fuse if you want stronger security guarantees." But the same topic is also discussed in many similar articles, e.g. more recently regarding the likeliness of opening new bugs for everyone using automount since the new EROFS filesystem has been merged into the mainline kernel.

poettering 7y ago
Yes this is a problem. To address this systemd-homed is careful to validate the user record enclosed in the volume first (which includes checking its signature against the keyring of accepted record signers) and checks whether the provided user password can unlock it. Only after this validation and that the fs actually matches the record we will mount it. Thus as long as the employer trusts its employees enough things should be reasonably safe. (To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs)
- Mrat 7y ago
  Hi, Lennart. My question isn't related to what you were answering in this comment but it's related to some problems I have to deal since I'm constantly moving my /home folder from a distribution to another. I always have to delete files like ~/.local/share/applications/.desktop because otherwise it will show stuff that shouldn't be available in a freshly-installed distribution and it makes me think it's "contaminated"*. I wanted to know how this new implementation deals with those cases. BTW, congratulations! You made a systemd "hater" like me agree with you. I would be really grateful if this solution made me forget about cleaning up my home before a new install. Have a nice day!

sifar 7y ago

May be this is a naive question, but it talks about making home directories portable. In that case how does it resolve when two different users on two different machines with the same username try to move it to the same stick ? How does it guarantee unique UIDs across different machines ?

waste_monk 7y ago

Cancer now working to improve brain tissue handling.

AstralStorm 7y ago

So instead of writing a PAM module like normal people... Wait, it already exists. pam_mount, used to typically mount ecryptfs. Welcome to NIH.

poettering 7y ago
Uh oh. This is implemented via a PAM module too. But it does substantially more than pam_mount so not sure what you want. It's like claiming that UNIX 'find' is NIH because 'ls' already can show directory listings.