<div dir="ltr"><div dir="ltr">On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL <<a href="mailto:thomas.hummel@pasteur.fr">thomas.hummel@pasteur.fr</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
if I try to sum up all of your answers, I come to the following <br>
understanding :<br>
<br>
- sessions are always created via the pam_systemd module<br>
- which is, in my case called (sshd, crond) via the password-auth stack <br>
include<br>
- so crond, through pam_systemd will cause a session to be created<br></blockquote><div><br></div><div>If you specifically mean systemd-logind sessions, yes.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- such session is created via the sd-pam helper responsible for <br>
pam_open_session() and pam_close_session() calls<br></blockquote><div><br></div><div>Not exactly. For cron and sshd, all those PAM functions are called directly by cron or sshd themselves.</div><div><br></div><div>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.</div><div><br></div><div>As far as I could figure out, the entire process works like this:</div><div><br></div><div><font face="monospace">sshd (listener)</font></div><div><font face="monospace">└ sshd (connection worker)</font></div><div><font face="monospace"> ├ pam_start(sshd, ...)</font></div><div><font face="monospace"> ├ pam_acct_mgmt()</font></div><div><font face="monospace"> │ └ pam_access.so</font></div><div><font face="monospace"> ├ pam_open_session()</font></div><div><font face="monospace"> │ └ pam_systemd.so</font></div><div><font face="monospace"> │ └ DBus call to systemd-logind: CreateSession(service=sshd, uid=1000)</font></div><div><font face="monospace"> ├ fork login shell</font></div><div><font face="monospace"> │ └ /bin/bash</font></div><div><font face="monospace"> └ pam_close_session()</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">systemd-logind</font></div><div><font face="monospace">└ receives CreateSession(uid=1000)</font></div><div><span style="font-family:monospace"> ├ DBus call to systemd: Start(user@1000.service)</span><br></div><div><div><font face="monospace"></font></div><div><font face="monospace"> └ DBus call to systemd: StartTransientUnit(session-1234.scope)</font></div></div><div><font face="monospace"><br></font></div><div><font face="monospace">systemd (pid1)</font></div><div><font face="monospace">└ user@1000.service</font></div><div><font face="monospace"> └ sd-pam</font></div><div><font face="monospace"> ├ pam_start(systemd-user, ...)</font></div><div><font face="monospace"> ├ pam_acct_mgmt()</font></div><div><font face="monospace"> │ └ pam_access.so</font></div><div></div><div><span style="font-family:monospace"> ├ pam_open_session()</span></div><div><span style="font-family:monospace"> ├ fork sd-pam child</span></div><div><span style="font-family:monospace"> │ └ sd-pam (waits for parent to exit)</span></div><div><span style="font-family:monospace"> │ └ pam_close_session()</span></div><div><span style="font-family:monospace"> └ exec systemd --user</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- such a worker is started by a systemd --user instance<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>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'.<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- so a user crontab will ultimately cause the use of the already running <br>
systemd --user instance of the user (because his logged in or is <br>
lingered) OR the creation of a systemd --user instance for the purpose <br>
of the crond session creation<br></blockquote><div><br></div><div>Yes, more or less.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What I still don't quite get is :<br>
<br>
- is it sd-pam or systemd --user or user@<uid>.service holding them <br>
which uses the systemd-user pam service name ?<br></blockquote><div><br></div><div>user@<uid>.service is where the name is configured, but sd-pam is the process which actually calls PAM for that service name.</div><div><br></div><div>systemd --user on its own doesn't talk to PAM at all. (See what I wrote above about the sd-pam worker.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- my understanding was that pam service name is passed to pam_start() : <br>
in the user crontab case, my guess is that crond does this call with the <br>
crond service name (so pam knows what module stacks to run).<br>
So this would mean something like the user@<uid>.service (or sd-pam) <br>
would itself call pam_start(systemd-user, ...) when called by pam_systemd ?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So basically pam_systemd module would trigger another service which <br>
itself would go through pam with the systemd-user service name ?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- again, why is a first ssh login session able to create the user <br>
session without the user having to be listed for systemd-user in <br>
access.conf whereas crond semmes to need it (givent no systemd --user <br>
was previously running in both cases) ?<br></blockquote><div><br></div><div>I don't know why you're seeing the different behavior between crond and sshd.</div><div><br></div><div>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`.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>