Bug 2085485

Summary:	RFE: get systemd-homed hooked up
Product:	[Fedora] Fedora	Reporter:	Lennart Poettering <lpoetter>
Component:	authselect	Assignee:	Pavel Březina <pbrezina>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	36	CC:	aboscatt, cglombek, jhrozek, mzeuom, pbrezina, robert.mader
Target Milestone:	---	Keywords:	Reopened, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	authselect-1.4.2-1.fc37	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-12-09 01:31:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1806949

Description Lennart Poettering 2022-05-13 13:14:38 UTC

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.

Comment 1 Pavel Březina 2022-05-26 13:23:20 UTC

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?

Comment 2 Andre Boscatto 2022-06-23 02:16:58 UTC

Ping

Comment 3 Pavel Březina 2022-07-08 11:07:22 UTC

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

Comment 4 Lennart Poettering 2022-07-08 15:18:28 UTC

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

Comment 5 Pavel Březina 2022-07-11 12:31:57 UTC

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".

Comment 6 Lennart Poettering 2022-07-11 13:41:41 UTC

> 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

Comment 7 Pavel Březina 2022-07-18 10:24:46 UTC

Upstream PR: https://github.com/authselect/authselect/pull/311

Comment 11 Fedora Update System 2022-12-01 14:01:40 UTC

FEDORA-2022-9b9adb4d6d has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9b9adb4d6d

Comment 12 Fedora Update System 2022-12-02 02:28:52 UTC

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.

Comment 13 Fedora Update System 2022-12-05 15:46:00 UTC

FEDORA-2022-3905763e94 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3905763e94

Comment 14 Fedora Update System 2022-12-06 01:32:17 UTC

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.

Comment 15 Fedora Update System 2022-12-09 01:31:44 UTC

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.

Comment 16 Robert Mader 2022-12-09 12:55:58 UTC

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.

Comment 17 Pavel Březina 2022-12-09 13:35:46 UTC

If this is desired, then systemd folks should drive a Fedora Change page to change the default settings.