On Fri, Oct 16, 2020 at 4:13 PM Thomas HUMMEL <thomas.hum...@pasteur.fr> wrote:
> > On 16/10/2020 13:22, Mantas Mikulėnas wrote: > > > 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. > > Yes I probably did. > My undestanding is that a pam session is anything pam modules do between > pam_open_session() and pam_close_session(), which could be things like > write to /var/run/utmp for instance and a systemd-logind session is just > a scope holding all a user processes between his login and logout > Yes, that's right. > > [By the way I don't know how a child process can wait for its parent - > waiting for its parent to send a signal ?] > 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. > 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. > > So basically user@<uid>.service is a service using PAMName=systemd-user > with an sd-pam pam session handler and which main process (similar to an > ExecStart in a standard service unit) is systemd --user correct ? > Yes. > > Why has it got to work the other way around compared to as service > wainting for its child to finish to call pam_close_session() as you said ? > 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. (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.) > > > 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 the second sd-pam you mentionned in your tree above is this handler > mentionnend in the doc I mentionned and waiting for systemd --user to > finish to take proper action when closing the pam session ? > 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.) > Regarding the following part : > > > systemd-logind > > └ receives CreateSession(uid=1000) > > ├ DBus call to systemd: Start(user@1000.service) > > └ DBus call to systemd: StartTransientUnit(session-1234.scope) > > Since you said systemd-logind does not need systemd --user to creates > the session I guess the second job (start transient unit) can be done > without it. So can I conclude that this is just the way systemd-logind > is designed : when instructed to create a session, it also start the > user@<uid>.service just for the user to be able to use its own systemd > instance (which in my case of user crontab is not used) ? > Yes. -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
