Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. 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#75509 - [util-linux] PAM configuration shipped for su does not work with systemd-homed

Attached to Project: Arch Linux
Opened by Zhao4 She4 (zhs) - Thursday, 04 August 2022, 12:11 GMT
Last edited by Toolybird (Toolybird) - Thursday, 11 August 2022, 06:34 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description:

When a user account is created and managed by systemd-homed one cannot correctly su to that user when logged in as another user. This happens because the pam.d files shipped with util-linux have not been updated to include Arch's homed-aware system-auth stack.

Additional info:
* 2.38-1 (no changes to /etc/pam.d/su or /etc/pam.d/su-l in 2.38.1-1)

Steps to reproduce:

Create systemd-homed-managed accounts user1 and user2.

While logged in as user1 via system local login which correctly includes system-auth and works as expected with homed, attempt:

su - user2

The first stage of login goes well but since pam_systemd_home.so is not used in default /etc/pam.d/su and/or /etc/pam.d/su-l, and /etc/pam.d/system-auth is not included in them either, systemd-homed is not notified and the user directory is not mounted to /home/user2 resulting in user2's shell giving permission error messages.

Now, attempt:

cd

or

ls

Both result in permission errors because with systemd-homed /home/user2 is empty, and normally owned and readable only by root, until /home/user2.homedir (or equivalent luks-encrypted file) is mounted over it.

Adding:

auth include system-auth

to /etc/pam.d/su-l fixes the problem.

A workaround is to first do:

homectl activate user2

and then su to user2. However, this results in homed not being aware of the following authentication and attempting to deactivate and unmount /home/user2 repeatedly. It will report the user home in homectl list output as lingering. As soon as the shell authenticated as user2 is closed, deactivation succeeds but this is only a lucky side-effect of homed not giving up on unmounting.
This task depends upon

Loading...