Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#65819 - [pambase] support systemd-homed

Attached to Project: Arch Linux
Opened by hexchain (hexchain) - Friday, 13 March 2020, 10:42 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:46 GMT
Task Type Feature Request
Category Packages: Core
Status Assigned   Reopened
Assigned To Christian Hesse (eworm)
David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 14
Private No

Details

Description:
To make use of systemd-homed one needs to modify its PAM configuration. However, changing PAM configuration can be dangerous and there does not seem to be any consensus on how to do it[1]. It would be better if Arch has some recommended solution.

P.S.: not sure if this is relevant but pam_permit.so seems to be a problem[2] if we would like to allow login with either pam_unix or pam_systemd_home.

[1] https://wiki.archlinux.org/index.php/Talk:Systemd-homed
[2] https://bbs.archlinux.org/viewtopic.php?id=245892
This task depends upon

Comment by Chandradeep Dey (chandradeepdey) - Saturday, 14 March 2020, 00:39 GMT
tried to make as few changes as i could to add systemd-homed
Comment by oud54036@zzrgg.com (soredake) - Sunday, 29 March 2020, 11:17 GMT
Any progress on this?
Comment by Fabian (Tids) - Sunday, 24 May 2020, 13:02 GMT
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
Comment by loqs (loqs) - Friday, 31 July 2020, 21:38 GMT
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?
Comment by tinywrkb (tinywrkb) - Wednesday, 19 August 2020, 11:31 GMT
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.
Comment by David Wheeler (dwheeler) - Sunday, 23 August 2020, 13:47 GMT
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. :(
Comment by loqs (loqs) - Sunday, 23 August 2020, 18:05 GMT
@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.
Comment by David Wheeler (dwheeler) - Sunday, 23 August 2020, 22:41 GMT
@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.
Comment by loqs (loqs) - Sunday, 23 August 2020, 22:54 GMT
Oops authtok needs to be new_authtok_reqd. Please try this updated version.
Comment by Vilgot Fredenberg (Metztli) - Monday, 24 August 2020, 13:12 GMT
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?
Comment by loqs (loqs) - Monday, 24 August 2020, 17:16 GMT
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.
Comment by David Wheeler (dwheeler) - Monday, 24 August 2020, 21:52 GMT
@loqs, the latest config allows the user to login, but it isn't enforcing the password change before logging the user in.
Comment by loqs (loqs) - Monday, 24 August 2020, 22:16 GMT
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
Comment by loqs (loqs) - Monday, 24 August 2020, 23:13 GMT
  • Field changed: Percent Complete (100% → 0%)
Implementation of this feature caused breakage for existing passwd users, who use the expire password feature. This is unrelated to journal messages from systemd.
Comment by Doug Newgard (Scimmia) - Monday, 24 August 2020, 23:14 GMT
Note: you aren't going to get a response from dwheeler, as he's been banned for hijacking another ticket.
Comment by Chandradeep Dey (chandradeepdey) - Tuesday, 25 August 2020, 21:20 GMT
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.
Comment by loqs (loqs) - Tuesday, 25 August 2020, 21:50 GMT
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
Comment by Chandradeep Dey (chandradeepdey) - Wednesday, 26 August 2020, 11:31 GMT
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.
Comment by Chandradeep Dey (chandradeepdey) - Wednesday, 26 August 2020, 12:10 GMT
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
Comment by Chandradeep Dey (chandradeepdey) - Wednesday, 26 August 2020, 13:06 GMT
I just read the previous comments and forum discussions and found that things like new_authtok_reqd were already covered. Sorry for repeating those.
Comment by loqs (loqs) - Wednesday, 26 August 2020, 17:40 GMT
@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.
Comment by Chandradeep Dey (chandradeepdey) - Wednesday, 26 August 2020, 22:40 GMT
@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?
Comment by loqs (loqs) - Wednesday, 26 August 2020, 22:55 GMT
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/
Comment by Chandradeep Dey (chandradeepdey) - Thursday, 27 August 2020, 10:11 GMT
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)
Comment by loqs (loqs) - Thursday, 27 August 2020, 11:19 GMT
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.
Comment by Chandradeep Dey (chandradeepdey) - Thursday, 27 August 2020, 13:08 GMT
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.
Comment by loqs (loqs) - Thursday, 27 August 2020, 13:16 GMT
The substack approach avoids using jump and the related issues, it seems to resolve all the issues.
Comment by Chandradeep Dey (chandradeepdey) - Thursday, 27 August 2020, 14:01 GMT
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.
Comment by loqs (loqs) - Thursday, 27 August 2020, 15:55 GMT
User with expired password can login with the attached system-auth.
Comment by Chandradeep Dey (chandradeepdey) - Friday, 28 August 2020, 23:00 GMT
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.
Comment by Chandradeep Dey (chandradeepdey) - Saturday, 29 August 2020, 23:35 GMT
I posted a new issue upstream - https://github.com/systemd/systemd/issues/16906. Let's take the discussion there.
Comment by Chandradeep Dey (chandradeepdey) - Sunday, 30 August 2020, 10:38 GMT
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.
Comment by Vignesh Balasubramaniam (viggy96) - Friday, 11 September 2020, 17:16 GMT
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.
Comment by Fabian (Tids) - Friday, 11 September 2020, 17:36 GMT
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.
Comment by Vignesh Balasubramaniam (viggy96) - Friday, 11 September 2020, 20:15 GMT
Interesting, my user was also part of the wheel group, but I still had trouble using sudo.
Comment by loqs (loqs) - Friday, 11 September 2020, 20:22 GMT
systemd-homed groups support is FS#67658
Comment by Chandradeep Dey (chandradeepdey) - Monday, 14 September 2020, 12:57 GMT
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.
Comment by Sean Tully (multipitch) - Monday, 12 October 2020, 13:51 GMT
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
Comment by Chandradeep Dey (chandradeepdey) - Monday, 12 October 2020, 14:01 GMT
@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.
Comment by Sean Tully (multipitch) - Tuesday, 13 October 2020, 12:36 GMT
@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.
Comment by loqs (loqs) - Tuesday, 13 October 2020, 21:40 GMT
@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?
Comment by Chandradeep Dey (chandradeepdey) - Tuesday, 13 October 2020, 23:50 GMT
@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.
Comment by loqs (loqs) - Wednesday, 21 October 2020, 21:51 GMT
[1] fixes pam_systemd_homed.so, thank you chandradeepdey. That leaves handling new_authtok_reqd.

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

Loading...