On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL <thomas.hum...@pasteur.fr> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel