<div dir="ltr"><div dir="ltr">On Fri, Oct 16, 2020 at 4:13 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"><br>
On 16/10/2020 13:22, Mantas Mikulėnas wrote:<br>
<br>
> But I think you're still confusing the two different kinds of "sessions" <br>
> that exist here. PAM open_session creates a PAM session, which <br>
> eventually *causes* a systemd-logind session to be created, but isn't <br>
> 100% the same thing.<br>
<br>
Yes I probably did.<br>
My undestanding is that a pam session is anything pam modules do between <br>
pam_open_session() and pam_close_session(), which could be things like <br>
write to /var/run/utmp for instance and a systemd-logind session is just <br>
a scope holding all a user processes between his login and logout<br></blockquote><div><br></div><div>Yes, that's right.</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>
[By the way I don't know how a child process can wait for its parent - <br>
waiting for its parent to send a signal ?]<br></blockquote><div><br></div><div>I haven't actually checked, but I'm guessing it uses prctl(PR_SET_PDEATHSIG). The kernel can automatically send a signal when this is enabled.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> No, it's actually started by the systemd system manager itself, because <br>
> user@.service has PAMName= set. It only *appears* to be a child of <br>
> systemd --user, because it is a child of the process which first forked <br>
> sd-pam, then exec'd systemd --user.<br>
<br>
So basically user@<uid>.service is a service using PAMName=systemd-user <br>
with an sd-pam pam session handler and which main process (similar to an <br>
ExecStart in a standard service unit) is systemd --user correct ?<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>
Why has it got to work the other way around compared to as service <br>
wainting for its child to finish to call pam_close_session() as you said ?<br></blockquote><div><br></div><div>If I remember correctly, it's so that the main process would still be able to have pid 1 as its parent, without introducing an intermediate step in the process tree.</div><div><br></div><div>(pid 1 itself cannot call PAM directly because PAM modules can block and they often modify process-wide state, so it has to fork at least once before handling PAM. So if that first child just forked ExecStart as a 2nd-level child process, this would mean a weird difference in behavior between services which use PAMName= and those which don't.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> Most tools (sudo, sshd, crond) handle all PAM calls in the parent <br>
> process, just forking your shell or cronjob as a child, then waiting for <br>
> the child to exit before they can call pam_close_session(). Systemd does <br>
> it the other way around – it also forks, but the *child* waits for the <br>
> parent to exit before calling pam_close_session(), whereas the parent <br>
> directly execs the ExecStart command.<br>
<br>
So the second sd-pam you mentionned in your tree above is this handler <br>
mentionnend in the doc I mentionned and waiting for systemd --user to <br>
finish to take proper action when closing the pam session ?<br></blockquote><div><br></div><div>Yes. (Actually in my diagram, I probably shouldn't have labelled the *first* process "sd-pam" -- I think it actually labels itself "sd-executor", as it handles all other environment preparation as well.)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regarding the following part :<br>
<br>
 > systemd-logind<br>
 > └ receives CreateSession(uid=1000)<br>
 >    ├ DBus call to systemd: Start(user@1000.service)<br>
 >    └ DBus call to systemd: StartTransientUnit(session-1234.scope)<br>
<br>
Since you said systemd-logind does not need systemd --user to creates <br>
the session I guess the second job (start transient unit) can be done <br>
without it. So can I conclude that this is just the way systemd-logind <br>
is designed : when instructed to create a session, it also start the <br>
user@<uid>.service just for the user to be able to use its own systemd <br>
instance (which in my case of user crontab is not used) ?<br></blockquote><div><br></div><div>Yes.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>