Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
homed isn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.
user-password based encryption of the home directory, so the password is required to unlock it (no admin access)
That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
SElinux is a “global ACL.” You can stop root from doing anything you like with it. Usually by accident and without realizing it’s been done in my experience…
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
Oh, I was specifically thinking that admins that have users either competent enough not to forget/lose their passwords or mature enough not to whine to the admin when that causes the loss of all their files are pretty niche.
I don’t know, unless I personally allow the admin to have that kinda access to my files I wouldn’t really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.
It’s the same drama as with the home directory replacement they announced and that no-one ever used.
homedisn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
Let me introduce you to selinux.
no…nonono… AHHHHH! - Vegita DBZA
In what way does selinux allow your users to lock themselves out of their own home directories in a way that the admin can not fix?
SElinux is a “global ACL.” You can stop root from doing anything you like with it. Usually by accident and without realizing it’s been done in my experience…
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
That’s true - you can often recover a bad ACL. I was thinking more of the “niche use case” where separating duties and restricting root are concerned.
Oh, I was specifically thinking that admins that have users either competent enough not to forget/lose their passwords or mature enough not to whine to the admin when that causes the loss of all their files are pretty niche.
I don’t know, unless I personally allow the admin to have that kinda access to my files I wouldn’t really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.