Hide Forgot
I'd really like to get systemd-homed hooked up with PAM by default on Fedora. (It's shipped in systemd-udev.rpm) What's the approach to get this done? It's quite well tested by now by other distros (specifically: arch), and I'd like it if we could enable this to just work on Fedora too. It's a matter of making pam_systemd_home.so appear in all four PAM stacks, usually pretty early on. It should not have any effect if homed is not installed or enabled (i.e. it will gracefully fallback). The module doesn't do anything for users not managed by systemd-homed. Docs for the PAM module are here: https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html I currently manually patch it into /etc/pam.d/system-auth so that the file then looks like this: ``` auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_fprintd.so auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok -auth sufficient pam_systemd_home.so auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular auth sufficient pam_sss.so forward_pass auth required pam_deny.so -account sufficient pam_systemd_home.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_usertype.so issystem account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so -password sufficient pam_systemd_home.so password requisite pam_pwquality.so local_users_only password sufficient pam_unix.so yescrypt shadow nullok use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd_home.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so ``` (and simple for the password-auth stack) (if you wonder why this skips the pwquality module in the password stack: homed links against that directly, so validating this via PAM is redundant) In my PoV it would be simplest to just add the module to all profiles, given it only does anything for homed's own users. i.e. it can be used in conjunction with any other form of userdb, since it only manages its own little subset of users, and can run side by side with everything else.
Hi Lennart, I am not familiar with systemd-homed yet so I have few questions: - Should this change go also into RHEL? Which version? - Why does it have to be on all four stages? Shouldn't only auth and password be sufficient? (that's were ecryptfs goes) - Why is it after pam_unix but before pam_sss? And especially why is it 'sufficient' and not 'optional'? If the module succeeds you just authenticated the user. E.g. pam_ecryptfs is in postlogin, isn't it a better place?
Ping
There is an open pull request on upstream and it is something we should work on. Let's keep it open. https://github.com/authselect/authselect/pull/311
Hi Lennart, I am not familiar with systemd-homed yet so I have few questions: > - Should this change go also into RHEL? Which version? I cannot say anything about that. Not at Red Hat anymore. It's a desktop thing though. In the long run I am very sure this should become the default across the board, but of course, that's my own opinion, and I am very sure plenty people disagree with that. > - Why does it have to be on all four stages? Shouldn't only auth and password be sufficient? (that's were ecryptfs goes) homed unifies the definition of the user in many ways with the home directory itself. i.e. it carries a user definition in a JSON format (this one: https://systemd.io/USER_RECORD/) which is a lot more expressive than /etc/passwd, and it's directly embedded in the home dirs, so that the home dirs are self-contained, and carry the full definition of the user. This stuff is quite expressive, it not only carries the basic metadata from /etc/passwd, but also the secrets from /etc/shadow, the account limits from there, plus a lot more. We synthesize NSS records from this data, but there's a lot of stuff that homed supports that you cannot do with classic unix user records (i.e. simple stuff like setting nice level for the user or so). It also directly supports fido2 + pkcs11 authentication, since it binds disk encryption to secrets released through that. Because of that it needs to be in all four stacks: authentication (because it needs the user password/pin/… to pass to the pkcs11/fido2 deivce to release the disk encryption), account (because it manages the account validity in detailed ways), passwd (because it allows changing passwords through PAM), session (because that is where nice level and so on is defined). > - Why is it after pam_unix but before pam_sss? And especially why is it 'sufficient' and not 'optional'? If the module succeeds you just authenticated the user. E.g. pam_ecryptfs is in postlogin, isn't it a better place? I don't know SSS that well, but basically i wanted to avoid that for users homed manages we'll ever go to the network. homed manages its own authentication, hence once that succeeded the access should be allowed, I am not sure why sssd would also do something about that. i.e. homed is strictly local only and thus very quick in determining whether a user is managed by it or not. sssd might involve network communication iirc, and thus is a bit slower potentially, so i figured i put the quick local thing first, and the potentially slower potentially remote stuff later. And I put pam_unix first simply because i wanted to disrupt the root user (and other classic UNIX users) as little as possible
Thanks, I wasn't aware that pam_systemd_homed does anything else than mounting the directory. If it also perform authentication than "sufficient" is indeed correct, also the location looks fine. Perhaps you should change the man page as it talks only about "Automatically mount home directories managed by systemd-homed.service on login, and unmount them on logout".
> Perhaps you should change the man page as it talks only about "Automatically mount home directories managed by systemd-homed.service on login, and unmount them on logout". https://github.com/systemd/systemd/pull/23975
Upstream PR: https://github.com/authselect/authselect/pull/311
FEDORA-2022-9b9adb4d6d has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9b9adb4d6d
FEDORA-2022-9b9adb4d6d has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-9b9adb4d6d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9b9adb4d6d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-3905763e94 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3905763e94
FEDORA-2022-3905763e94 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-3905763e94` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3905763e94 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-3905763e94 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
With authselect 1.4.2 this now works great, however it still requires manual enablement via `authselect enable-feature with-systemd-homed`. Given that `systemd-homed.service` appears to be enabled by default on Fedora, shouldn't this feature get enabled by default as well? If preferred, I can open a new issue to track that.
If this is desired, then systemd folks should drive a Fedora Change page to change the default settings.