Arch Linux

tried to make as few changes as i could to add systemd-homed

Any progress on this?

I've made an AUR[1] pkg that includes the changes from the Wiki[2]. Works so far with normal users, as well as homed-users.

[1] https://aur.archlinux.org/packages/pambase-homed/
[2] https://wiki.archlinux.org/index.php/Systemd-homed#Enabling_PAM_modules

What about other packages that provide pam services that use pam_unix for auth, account or password?
cronie, shadow, util-linux, bftpd, cups, lightdm, posgresql, samba, screen, at, deepin-daemon, fcron, fscrypt, open-vm-tools, opendoas, partimage, physlock, schroot, sssd and vsftpd?

The supplied /etc/pam.d/system-auth in the latest 20200721.1-2 pambase package works great for me.
I switched from the suggested nss-auth on the wiki page to the default supplied system-auth.
Storage is directory (no encryption) but I have pam_mount with encfs and it's still working fine.
So this issue is probably resolved, unless someone else noticed some issues.

I'm experiencing the issue described here: https://bbs.archlinux.org/viewtopic.php?id=258297

Using the second sample system_auth in post #8 (the one labeled "pam_unix always checked byefore pam_systemd_home") resolves the spurious journal messages. It would be nice if this was the out of the box configuration, so that all of us users with out-of-the-box configs for pam and systemd (with systemd-homed NOT enabled) don't see these noisy, meaningless journal entries.

EDIT:
Never mind. The configuration that switches the order of pam_unix and pam_systemd_home breaks required password changes (logs attached), at least via tty and ssh, and I don't know enough about PAM to suggest a working config. :(

@dwheeler does pambase 20200721.1-2 work with required password changes?
If not please try the attached system-auth.
Edit:
If it only works for passwd based accounts.

@loqs pambase 20200721.1-2 does work with required password changes, but as discussed in https://bbs.archlinux.org/viewtopic.php?id=258297, it's leaving a lot of needless journal/system entries on every auth attempt. The only way I've found to get rid of these entries, without breaking password changes, is to use the other configuration from that post (the one with pam_systemd_home.so entries completely removed).

Your attached changes allow password changes, but breaks logins.

Oops authtok needs to be new_authtok_reqd. Please try this updated version.

Isn't the issue rather that systemd-homed.service and systemd-userdbd.socket are inactive and are supposed to be active for pam_systemd_home?

Metztli please wait for dwheelers response as the implementation of systemd-homed support caused the change:
to
auth [success=2 default=ignore] pam_unix.so try_first_pass nullok
from
auth required pam_unix.so try_first_pass nullok
which expands to
auth [success=ok new_authtok_reqd=ok ignore=ignore default=bad] pam_unix.so try_first_pass nullok
success=ok to success=2, the merging of ignore=ignore default=bad to default=ignore were intended, the merging of new_authtok_reqd into default=ignore was under the assumption it would never be produced.

@loqs, the latest config allows the user to login, but it isn't enforcing the password change before logging the user in.

If you follow [1] to revert pambase to 20190105.1-2 while keeping pam 1.4 does that enforce the password change?

[1] https://bugs.archlinux.org/task/67636#comment191839

Implementation of this feature caused breakage for existing passwd users, who use the expire password feature. This is unrelated to journal messages from systemd.

Note: you aren't going to get a response from dwheeler, as he's been banned for hijacking another ticket.

btw, using pam_systemd_home.so's output to conditionally skip pam_unix.so is a bad idea because pam_systemd_home.so likes to return PAM_SUCCESS on PAM_USER_UNKNOWN some times. I opened a PR https://github.com/systemd/systemd/pull/15118#issuecomment-601443856 here. Then I realised that the PR was dumb because half the situations didn't need to be changed and the other half could be avoided by simply not doing the [success=N] shenanigans.

You proposed solution then would be the substack approach? Your proposed solution in https://bugs.archlinux.org/task/65819#comment187386 is invalid?

If there is a an exploitable security issue please report it to security@archlinux.org

pam_systemd_home.so
auth - returns PAM_USER_UNKNOWN when required (acquire_home -> acquire_user_record can return that)
account - returns PAM_SUCCESS on PAM_USER_UNKNOWN (has a test on acquire_home's return value)
password - returns PAM_USER_UNKNOWN when required (same as auth)
session - returns PAM_SUCCESS on PAM_USER_UNKNOWN (same as account)
--------------------
my proposed solution in comment 187386
Yes. it assumes that account and session return PAM_USER_UNKNOWN when the user is unknown to homed. I just changed the required control value, which expands to [success=ok new_authtok_reqd=ok ignore=ignore default=bad]. I replaced the 'ok' to skip 1 instead, and added a user_unknown=ignore.
It also skips pam_unix.so in session if pam_systemd_homed succeeds. This is unnecessary since the session part of pam_unix.so only does some logging.

The solution I proposed there was further debated upon in the wiki's talk page for systemd-homed. Skidnik introduced me to the idea of a substack, and I proposed a substack config where the only two that needed a substack were put in the substack. Skidnik changed that to include all systemd-homed's in a single substack, which is what was added to the wiki.
--------------------
Requirement of substack
Substacks can be easily replaced with [...] syntax
For example -
auth substack homed-substack
auth required pam_env.so

homed-substack
auth sufficient pam_unix.so try_first_pass nullok
auth sufficient pam_systemd_home.so suspend=true
auth [success=bad] pam_permit.so

can be replaced with -
auth [success=2 new_authtok_reqd=2 default=ignore] pam_unix.so try_first_pass nullok
auth [success=1 new_authtok_reqd=1 default=ignore] pam_systemd_home.so suspend=true
auth [success=bad] pam_permit.so
auth optional pam_permit.so
auth required pam_env.so
--------------------
Current problem 1
as stated in pam_systemd_home.so, account returns success on user_unknown. So the
account [success=1 default=ignore] pam_systemd_home.so
used in /etc/pam.d/system-auth is bad
--------------------
Current problem(?) 2
Is there any particular reason why session for pam_systemd_homed.so is omitted from /etc/pam.d/system-auth? It seems like it does much more work than pam_unix.so's logger.
--------------------
Security
I don't think this affects security, because account assumes that the user is already properly authenticated. I am not an expert in anything, so can't guarantee this.
--------------------
Other problems
forget-key-on-suspend will soon be available on at least GNOME (hopefully others), but never on TTY sessions. So we would need two system-auth files. One to be included for TTY sessions, other by forget-key-on-suspend supporting session managers.

Some more details
Replacing the substack -
sufficient expands to [success=done new_authtok_reqd=done default=ignore]. I replaced the 'done' with an appropriate number of lines to skip
-------------------------
Solution to problem 1
use pam_unix.so's return status to skip pam_systemd_home.so. Not the other way around.
-------------------------
Solution to problem(?) 2
Add session optional pam_systemd_home.so
-------------------------
Problem 3 (password change/expiry not working properly)
This is because in the current configuration, new_authtok_reqd is counted in default instead of separately.
in all 4 keywords, success and new_authtok_reqd result in the same action
requisite - [success=ok new_authtok_reqd=ok ignore=ignore default=die]
optional - [success=ok new_authtok_reqd=ok default=ignore]
-------------------------
Solution to problem 3
Properly mimic the keywords instead of only half-mimicking them.
-------------------------
More stuff
Also check https://bugs.archlinux.org/task/67658 and the comment there

I just read the previous comments and forum discussions and found that things like new_authtok_reqd were already covered. Sorry for repeating those.

@chandradeepey any thoughts on https://bugs.archlinux.org/task/65819#comment192023 ?
dwheeler's response to my followup was the old pambase did enforce the password change. (response was posted in a different bug report and deleted)
My thought was try_first_pass option to pam_unix in passwd but the old pambase had that as well.

@loqs i set my account's password to expired
with the modified system-auth (attached) i was dropped straight into bash even though a message that i was required to change the password popped up. with the system-auth here https://github.com/archlinux/svntogit-packages/tree/4f61fe5dddfb8889b2d15d34e84d9cc3e60cc24f (no systemd-homed, no faillock) i got "Authentication token manipulation error" and couldn't login. I tried deleting the sha512 option, didn't change anything.

I don't think this is related to systemd-homed. Could be a bug in pam itself?

What if you add a password entry to /etc/pam.d/login  FS#61843  ?

Edit:
Default pambase 20200721.1-2 files, expired passwd account login is allowed without a password change.
removing
-account [success=1 default=ignore] pam_systemd_home.so
produces token authentication manipulation
adding
password include system-local-login
then password change is forced before login is allowed.

Edit2:
It is add you said [1]. For the auth check unix is first so is handled as expected.

[1] https://github.com/systemd/systemd/blob/v246/src/home/pam_systemd_home.c#L837

Edit3:
After applying pam.diff pambase 20200721.1-2 expired passwd account login is required to change password before login.
I was not criticizing you patch, the deletion was simply smaller.

Edit4:
From [2] 60001…60513 → UIDs for home directories managed by systemd-homed.service
account [default=1 success=ignore] pam_succeed_if.so uid >= 60001 uid <= 60513
skip over the following for accounts not managed by systemd-home
-account [success=1 default=ignore] pam_systemd_home.so

[2] https://systemd.io/UIDS-GIDS/

Criticising me - bruh do it as much as you want. i love debates and learning new stuff.

/etc/pam.d/login - ohhh, ye that works. it clearly was an issue for a long time, wonder why it wasn't fixed all this time. :/

My patch - it actually was like that, reporting PAM_USER_UNKNOWN. except i did it in session too. you can see that i renamed the PR and force pushed to the branch again. I changed to PAM_IGNORE because i thought that would allow simpler handling with the 4 keywords instead of with the [...] syntax.

auth - auth returns PAM_USER_UNKNOWN properly, so it can be second if needed. you linked to the account part in [1]. account and session are the one that return abnormal results, as i stated before.

your edit 3 - just applying the diff shouldn't work? i removed all homed mentions from my system-auth. it didn't work until your /etc/pam.d/login solution. i still think just putting account pam_systemd_homed.so second (with the login file patched) is good enough.

your edit 4 - any UID outside the system UID range (0-999?) can be picked during account creation. they recommend 60001-60513 inclusive, but that isn't mandatory. (man 1 homectl)

My preference would be pam_systmd_home not returning PAM_SUCCESS for users it does not manage.

With edit 4 I was trying to explicitly guarantee only accounts managed by pam_systemd_home are checked by pam_systemd_home by that module in account and password rather than the implicit guarantee provided by being the last module.

I just noticed that in https://bugs.archlinux.org/task/65819?getfile=19033 (which tries to imitate Arch's previous "account required pam_unix.so") if the user is unknown to both pam_unix and pam_systemd_home, the second one will return a success and pam_deny will be skipped. Only the example in pam_systemd_home's manpage works (where they used sufficient instead). Now the question is if "sufficient" is the right thing to use. systemd-homed does mention that when this is reached, it is assumed that the user is already authenticated. If there are really no security issues with a sufficient followed by pam_permit.so, systemd-homed doesn't really need to change. But if "required"/N-line skipping is to be used, or if there are any security issues, the PR needs to be reopened.

60001-60513 - yes, i saw your link. but an user can override that while creating the user, and it is not forbidden to do so.

The substack approach avoids using jump and the related issues, it seems to resolve all the issues.

nah. jumping in substack is built-in. any substack can be equivalently implemented with the jump approach. here is the one that was in the wiki
system-auth
account substack nss-auth
account optional pam_permit.so
account required pam_time.so

nss-auth
account sufficient pam_unix.so
account sufficient pam_systemd_home.so
account required pam_deny.so

equivalent -
1 account [success=2 new_authtok_reqd=2 default=ignore] pam_unix.so
2 account [success=1 new_authtok_reqd=1 default=ignore] pam_systemd_home.so
3 account required pam_deny.so
4 account optional pam_permit.so
5 account required pam_time.so

When 2 returns success (lying) after 1 returns PAM_USER_UNKNOWN the move straight to 4 is what seems sketchy here. Whether it is actually sketchy or not decides if the PR needs to be reopened.

User with expired password can login with the attached system-auth.

k so i intensely stared at PAM's code, the 3 PAM guides, various applications under util-linux and shadow for 2 days. i think i have finally reached pam_enlightenment.

@loqs What is happening here (and similar ones i uploaded before), correct me if i am wrong please -
the retval of account pam_unix.so is PAM_NEW_AUTHTOK_REQD, the associated action is ignore. So pam_acct_mgmt's status remains PAM_MUST_FAIL_CODE and impression remains _PAM_UNDEF and we proceed to pam_systemd_home.so.
account pam_systemd_home.so returns PAM_SUCCESS because of the test that it does against PAM_USER_UNKNOWN, the associated action is to skip 1. The side effect is ignore, and so the return value and impression remain the same. we skip the pam_deny.so and land on pam_permit.so.
account pam_permit.so returns PAM_SUCCESS, associated action is ok. pam_acct_mgmt's status is changed to PAM_SUCCESS and impression is changed to _PAM_POSITIVE.
account pam_time.so probably returns PAM_SUCCESS, associated action is ok. since impression is _PAM_POSITIVE and retval is PAM_SUCCESS, the status is changed to the same PAM_SUCCESS. eventually this is returned to login.

login tests this against PAM_NEW_AUTHTOK_REQD, finds the test false. so it never calls pam_chauthtok. [If it did find PAM_NEW_AUTHTOK_REQD (default=ignore replaced by default=bad or something), pam_chauthtok would be called. This would need the /etc/pam.d/login fix.]
login then tests the value again if it is an error condition, finds the test false again. So it proceeds to call pam_open_session().
PAM doesn't actually block pam_open_session(), that's the application's responsibility.

I posted a new issue upstream - https://github.com/systemd/systemd/issues/16906. Let's take the discussion there.

It seems like digging a hole on the internet and proving myself a dumbass is something I won't be able to leave behind.

The attached system-auth preserves the return values for them to be tested by applications. This will block users with expired passwords from logging in. Adding the /etc/pam.d/login solution will cause such users to be forced to change the password (also, that fix needs to be applied to all applications that use pam_chauthtok, such as /etc/pam.d/sudo). This will also fix the current situation where trying to log in with a valid username but giving an invalid password has a different result than logging in with an invalid username (letting an outsider know what users exist).

Edit: urgh i give up. pam_unix's user_unknown tests are even worse. they just check if the username is valid with pam_get_user or something. The attached configuration doesn't work with systemd-home users because pam_unix just returns some other error. There is probably no way to preserve the error return values with the current situation.

I had another issue with pambase 20200721.1-2 and systemd-homed. While I could login correctly, I was unable to use sudo in the terminal. However pkexec did work. I had to add "-auth sufficient pam_systemd_home.so" to /etc/pam.d/sudo. Then I was able to use my account with sudo commands.

I can use sudo just fine. My homed-user is in the wheel group, wheel is allowed for sudo and that made it work for me.

Interesting, my user was also part of the wheel group, but I still had trouble using sudo.

systemd-homed groups support is  FS#67658 

I tested this one in as many scenarios as I could. Obviously, the solution is hacky and a fix from pam_systemd_home.so is still much better.

@loqs btw you could open a PR on systemd with the patch you posted here. the credit for that is still yours, even if it's 2 lines.

The current configuration of /etc/pam.d/system-auth - commit https://github.com/archlinux/svntogit-packages/commit/2d5af94ae55a5c98837ce9631f331ad2aad32bb3 has broken xrdp.
The line "-account [success=1 default=ignore] pam_systemd_home.so" needs to be commented out for xrdp session to work.
Under discussion here:
https://github.com/neutrinolabs/xrdp/issues/1684
https://github.com/microsoft/linux-vm-tools/issues/127
https://bbs.archlinux.org/viewtopic.php?id=258297

@multipitch try the system-auth mentioned above your comment (192788). This needs to be fixed upstream and that's the best we can do until that happens.

@chandradeepdey The file in 192788 didn't work for me. Commenting out "-account [success=1 default=ignore] pam_systemd_home.so" in system-auth from pambase 20200721.1-2 does work for me, so I'll continue to do that.

@chandradeepdey perhaps if you submit a PR upstream it might progress things?

@multipitch is systemd-homed enabled on the system with the issue? The pambase configuration does not need it to be it is a data point that would indicate where the issue might be.
Have you reported the issue upstream to systemd?

@multipitch could you add some pam_debug.so statements in the configuration of the attached file to see what exactly fails? I thought the only case I couldn't cover was an authinfo_unavail from pam_unix.so, everything else should have been preserved.

@loqs oh i wasn't submitting the PR because you posted the patch here. will do it then.

[1] fixes pam_systemd_homed.so, thank you chandradeepdey. That leaves handling new_authtok_reqd.

[1] https://github.com/systemd/systemd/commit/842067e6753d8cad951c83ac62681c539e1b1a07

Given the large amounts of unnecessary and misleading log spam caused by this change on default installs (without any benefit for most users), I suggest reverting this and let interested users add systemd_home manually (perhaps with commented examples).

See https://bbs.archlinux.org/viewtopic.php?id=258297

@chandradeepdey should new_authtok_reqd be added to pam_systemd_home.so entries as well as pam_unix.so as in the attached diff?

@loqs
auth portion only needs [success=N default=ignore] for both pam_unix.so and pam_systemd_home.so, they don't return new_authtok_reqd

account portion - pam_permit.so will turn both success and new_authtok_reqd into success. it needs to be like this -
account [success=ok new_authtok_reqd=ok default=1] pam_systemd_home.so
account [default=1] pam_permit.so
account required pam_unix.so
account required pam_time.so

minus in front of pam_systemd_home.so - arch won't build systemd without homed, and if it is really missing then pam will return a pam_success from the module which is also wrong because pam_unix.so will be skipped. (the minus is for missing pam_systemd_home.so, not for missing dbus-org.freedesktop.home1.service)

The substack approach to me is now easier to understand.

With the substack approach could that keep the minus for pam_systemd_home.so?
This allows those who have not enabled systemd_homed to NoExtract=usr/lib/security/pam_systemd_home.so to pacman.conf preventing the following message
pam_systemd_home(systemd-user:account): Failed to query user record: Unit dbus-org.freedesktop.home1.service not found.

@loqs sorry the minus sign returns PAM_MODULE_UNKNOWN. both substack and non-substack approaches work fine if user doesn't install pam_systemd_home.so.

With the current configuration, I have to log in twice in GDM.

There was a discussion on github about this and this is a working solution:

https://github.com/systemd/systemd/issues/20619#issuecomment-986697045

sc. swap pam_unix and pam_systemd_home in the auth section.

I suppose the substack approach using `sufficient` would work too (and would probably be neater).

Could we have an update on this?

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

I will try to look into this after upgrading for the current batch of changes irt shadow/pam/filesystem.