A call to pam_namespace is required so that children of user@.service end up in
a namespace as expected. pam_namespace gets called as part of the stack that
creates a session (login, sshd, gdm, etc.) and those processes end up in a
namespace, but it also needs to be called from our stack which is parallel and
descends from pid1 itself.
The call to pam_namespace is similar to the call to pam_keyinit that was added
in ab79099. The pam stack for user@.service
creates a new session which is disconnected from the parent environment. Both
calls are not suitable for inclusion in the shared part of the stack (e.g.
@system-auth on Fedora/RHEL systems), because for example su/sudo/runuser
should not include them.
Fixes#17043 (Allow to execute user service into dedicated namespace
if pam_namespace enabled)
Related to https://bugzilla.redhat.com/show_bug.cgi?id=1861836
(Polyinstantiation is ignored/bypassed in GNOME sessions)
rhel-only
Resolves: #2218184
Setting umask for user sessions via UMASK setting in /etc/login.defs is
a well-known feature. Let's make sure that user manager also runs with
this umask value.
rhel-only
Resolves: #2210145
Without this parameter, we would allow user@ to start if the user
has no password (i.e. the password is "locked"). But when the user does have a password,
and it is marked as expired, we would refuse to start the service.
There are other authentication mechanisms and we should not tie this service to
the password state.
The documented way to disable an *account* is to call 'chage -E0'. With a disabled
account, user@.service will still refuse to start:
systemd[16598]: PAM failed: User account has expired
systemd[16598]: PAM failed: User account has expired
systemd[16598]: user@1005.service: Failed to set up PAM session: Operation not permitted
systemd[16598]: user@1005.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation n ot permitted
systemd[1]: user@1005.service: Main process exited, code=exited, status=224/PAM
systemd[1]: user@1005.service: Failed with result 'exit-code'.
systemd[1]: Failed to start user@1005.service.
systemd[1]: Stopping user-runtime-dir@1005.service...
RHEL-only
Resolves: #2059553
Jan Macku
David Tardon
Troy Dawson