[systemd-devel] Crond session, pam_access and pam_systemd

[Mantas Mikulėnas]

On Mon, Oct 12, 2020 at 8:16 PM Thomas HUMMEL <thomas.hummel at pasteur.fr>
wrote:

> Thanks for your answer. Still I'm quite confused.
>
> On 12/10/2020 18:21, Mantas Mikulėnas wrote:
>
>
> > It's a worker process which calls pam_open_session() and
> > pam_close_session() on behalf of the user@<uid>.service unit.
>
> Well I may be misunderstanding but this user@<uid>.service seems like a
> top level (for this user) placeholder for various other services units
> and/or scope, among which the init.scope corresponding to the sd-pam and
> systemd --user processes).
>

Yes, but it is *not* a top level for *all* of the user's processes – just
for those that are managed through systemctl --user.


>
> So you mean that any service in this placeholder can and do use the
> sd-pam helper to call pam_open_session() and pam_close_session instead
> of doing it themselves, passing it the relevant PAMName ?
>

No, I'm talking about system (global) services.

user@<uid>.service, itself, is a system service.


>
>
> > So when you see sd-pam under user@<uid>.service, that means it's
> > handling the "systemd-user" PAM service.
>
> I'm not sure I understood in which cases this PAM service name is used
>

It's used in only one case: when starting the "user@<uid>.service" unit.


>
>
> > They're different but related. Systemd user sessions are always managed
> > through PAM (the pam_systemd module), so whenever cron calls
> > pam_open_session() it indirectly starts a systemd session as well.
>
> You mean crond running as the user who has his own crontab does call
> pam_open_session() which is defined in the pam_systemd module ?
> If this is correct, this has indeed nothing to do with the sd-pam
> pam_open_seesion() mentionned above or does it ?
>
>
Yes, they're completely separate PAM instances.


>
> >
> >     - what does the first error message refers to and why does the
> >     systemd-user pam service name get passed ? and by which systemd
> (system
> >     or user) ?
> >
> >
> > Your systemd --user instance is run as a service
>
> Yes I understood that. But again I'm not really sure what services or
> other units it is supposed to run if I didn't defined user custom
>

Well, that doesn't mean it shouldn't be started at all – for a few reasons:

1) pam_systemd doesn't know that you don't have any custom units.
2) Even if you don't have any units in ~/.config/systemd, there might be
package-installed ones in /usr/lib/systemd/user (such as gpg-agent.socket).
3) systemd --user can also be used for transient units via `systemd-run`.

Though, it's true that most of those things are about interactive logins.
Actually I kind of wish that pam_systemd would have an option to *only*
create the user-<uid>.slice cgroup but without starting user at .service...
(Arch Linux's /etc/pam.d/crond does not list pam_systemd at all, and it
hasn't really created any issues so far.)


> services. Is it responsible to run things like the user's UI termnials
> for instance ?
>

Generally no. Even though your login processes belong to a "user session",
they are not managed by user@<uid>.service in any way.


>
>
> > Because of that, the service needs to have its own PAM service name and
> > makes its own PAM calls independently from crond or anything else.
>
> Ok so it's this service (systemd --user) which uses the systemd-user PAM
> service name ? Passed to the generic sd-pam worker ? Correct ?
>

Yes.


>
> >
> >     - what is the failing systemd job the second message refers to ? Does
> >     this mean that the crond "session" gets created by the systemd --user
> >     instance (as some gnome apps in other contexts for instance) ?
> >
> >
> > No, it's mostly the opposite – the starting of user@<uid>.service is
> > triggered by crond opening its PAM session.
>
> Sorry I don't get it : what service exactly is started ? crond opening
> its PAM session does not cause a systemd --user to be instanciated or
>

It does *if* your distro's /etc/pam.d/cron[d] includes the pam_systemd
module. (So on Debian it does, on Arch it doesn't.)


> does it ? I thought the only way to have a systemd --user was through
> the creation via pam_systemd notifying systemd-logind at a user fist
> login (and/or to linger the user)
>

Yes but that's exactly what happens in cron as well. When crond calls PAM,
it does exactly the same thing as when a user logs in interactively – it
calls PAM open_session in pretty much the same way as e.g. sshd or console
login would. The only difference is the PAM service name (and therefore a
different /etc/pam.d config file).

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201012/d730587b/attachment-0001.htm>