On Fri, Oct 16, 2020 at 4:13 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
