]> git.ipfire.org Git - thirdparty/systemd.git/commit - src/login/pam_systemd.c
pam_systemd/pam_systemd_home: rework how we cache user records
authorLennart Poettering <lennart@poettering.net>
Thu, 7 May 2020 08:38:38 +0000 (10:38 +0200)
committerLennart Poettering <lennart@poettering.net>
Tue, 12 May 2020 15:38:32 +0000 (17:38 +0200)
commitdbe7fff4765bad673d214c7e3db7bc088e163bea
tree30439ce7ab6100d0a6d26a0a8c67a6948600ef2d
parent0289b4ec69b5d740a9e92e87d6d062f811d7d349
pam_systemd/pam_systemd_home: rework how we cache user records

Since acquiring user records involves plenty of IPC we try to cache user
records in the PAM context between our various hooks. Previously we'd
just cache whatever we acquired, and use it from the on, forever until
the context is destroyed.

This is problematic however, since some programs (notably sudo) use the
same PAM context for multiple different operations. Specifically, sudo
first authenticates the originating user before creating a session for
the destination user, all with the same PAM context. Thankfully, there
was a safety check for this case in place that re-validated that the
cached user record actually matched our current idea of the user to
operate on, but this just meant the hook would fail entirely.

Let's rework this: let's key the cache by the user name, so that we do
not confused by the changing of the user name during the context's
lifecycle and always, strictly use the cached user record of the user we
operate on.

Essentially this just means we now include the user name in the PAM data
field.

Secondly, this gets rid of the extra PAM data field that indicates
whether a user record is from homed or something else. To simplify
things we instead just cache the user record twice: once for consumption
by pam_systemd_home (which only wants homed records) and once shared by
pam_systemd and pam_systemd_home (and whoever else wants it). The cache
entries simply have different field names.
src/home/pam_systemd_home.c
src/login/pam_systemd.c