On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> wrote:
Hello,
if I try to sum up all of your answers, I come to the following
understanding :
- sessions are always created via the pam_systemd module
- which is, in my case called (sshd, crond) via the password-auth stack
include
- so crond, through pam_systemd will cause a session to be created
If you specifically mean systemd-logind sessions, yes.
But I think you're still confusing the two different kinds of "sessions" that exist here. PAM open_session creates a PAM session, which eventually *causes* a systemd-logind session to be created, but isn't 100% the same thing.
- such session is created via the sd-pam helper responsible for
pam_open_session() and pam_close_session() calls
Not exactly. For cron and sshd, all those PAM functions are called directly by cron or sshd themselves.
The sd-pam helper only does this task when systemd pid1 (the service manager) needs to call PAM for a service that has PAMName= set in its unit.
As far as I could figure out, the entire process works like this:
sshd (listener)
└ sshd (connection worker)
├ pam_start(sshd, ...)
├ pam_acct_mgmt()
│ └ pam_access.so
├ pam_open_session()
│ └ pam_systemd.so
│ └ DBus call to systemd-logind: CreateSession(service=sshd, uid=1000)
├ fork login shell
│ └ /bin/bash
└ pam_close_session()
systemd-logind
└ receives CreateSession(uid=1000)
├ DBus call to systemd: Start(user@1000.service)
└ DBus call to systemd: StartTransientUnit(session-1234.scope)
systemd (pid1)
└ user@1000.service
└ sd-pam
├ pam_start(systemd-user, ...)
├ pam_acct_mgmt()
│ └ pam_access.so
├ pam_open_session()
├ fork sd-pam child
│ └ sd-pam (waits for parent to exit)
│ └ pam_close_session()
└ exec systemd --user
- such a worker is started by a systemd --user instance
No, it's actually started by the systemd system manager itself, because user@.service has PAMName= set. It only *appears* to be a child of systemd --user, because it is a child of the process which first forked sd-pam, then exec'd systemd --user.
Most tools (sudo, sshd, crond) handle all PAM calls in the parent process, just forking your shell or cronjob as a child, then waiting for the child to exit before they can call pam_close_session(). Systemd does it the other way around – it also forks, but the *child* waits for the parent to exit before calling pam_close_session(), whereas the parent directly execs the ExecStart command.
So if you had a basic unit with "ExecStart=/bin/sleep 1h", if it also had User= and PAMName=, then you would see 'sd-pam' as a child of 'sleep 1h'.
- so a user crontab will ultimately cause the use of the already running
systemd --user instance of the user (because his logged in or is
lingered) OR the creation of a systemd --user instance for the purpose
of the crond session creation
Yes, more or less.
What I still don't quite get is :
- is it sd-pam or systemd --user or user@<uid>.service holding them
which uses the systemd-user pam service name ?
user@<uid>.service is where the name is configured, but sd-pam is the process which actually calls PAM for that service name.
systemd --user on its own doesn't talk to PAM at all. (See what I wrote above about the sd-pam worker.)
- my understanding was that pam service name is passed to pam_start() :
in the user crontab case, my guess is that crond does this call with the
crond service name (so pam knows what module stacks to run).
So this would mean something like the user@<uid>.service (or sd-pam)
would itself call pam_start(systemd-user, ...) when called by pam_systemd ?
Yes.
So basically pam_systemd module would trigger another service which
itself would go through pam with the systemd-user service name ?
Yes.
- again, why is a first ssh login session able to create the user
session without the user having to be listed for systemd-user in
access.conf whereas crond semmes to need it (givent no systemd --user
was previously running in both cases) ?
I don't know why you're seeing the different behavior between crond and sshd.
However, a systemd-logind session doesn't actually *need* user@.service (systemd --user), it can be created without. So even if user@<uid>.service could not be started due to PAM not authorizing it (or due to some other reason), this will still not prevent pam_systemd from registering the session and creating user-<uid>.slice and making it appear in `loginctl`.
Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
