[systemd-devel] Crond session, pam_access and pam_systemd

[Mantas Mikulėnas]

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

> Hello,
>
> Using systemd-239 on CentOS 8.2 I'm trying to figure out what exactly
> happens when a cron "session" is created. In particular, what
> corresponds to the following error messages I get while running a user
> crontab :
>
> 2020-10-12T14:27:01.031334+02:00 maestro-orbit systemd:
> pam_access(systemd-user:account): access denied for user `toto' from
> `systemd-user'
>
> 2020-10-12T14:27:01.036959+02:00 maestro-orbit crond[135956]:
> pam_systemd(crond:session): Failed to create session: Start job for unit
> user at 1000.service failed with 'failed'
>
> - What I'm doing :
>
> ssh to the host, sudo -u toto, crontab -e, exit
>
> so when toto's crontab gets executed toto has no running sessions
>
> - access.conf, for cron, has the line
>
> +:ALL:cron crond
>
> - If, I add
>
> +:toto:systemd-user
>
> the error messages do not occur anymore.
>
> My understanding is that for an standard logged-in user, pam_systemd
> registers the user sessions to systemd-logind and each logged-in user
> has a user slice holding all his session's scopes plus an init scope
> holding a user@<uid>.service which in turns holds at least a user
> instance of systemd (systemd --user) and "sd-pam".
>
> So my questions are:
>
> - what is sd-pam ?
>

It's a worker process which calls pam_open_session() and
pam_close_session() on behalf of the user@<uid>.service unit. (This feature
is generic and accessible to all .service units via PAMName=; however, the
PAM calls often set up various process-wide state, so they cannot be done
in pid1 itself – and they usually require privileges, so they cannot be
done in the systemd --user instance either.)

So when you see sd-pam under user@<uid>.service, that means it's handling
the "systemd-user" PAM service.


> - is a crond session different from a user session ?
>

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.

However, PAM itself only has a very abstract concept of "sessions"
and doesn't really care about systemd's definition of user sessions at all
– it just tells each module to do whatever it needs to do.


> - what pam service name does crond use ?
>

Either "cron" or "crond", depending on which cron implementation your
distro uses. Check which pam.d config file was already included by your
distro.


> - 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 – it is not a child of
crond, and is not directly associated with any session (neither systemd nor
PAM), but meant to be shared across all of them. It's shared between cron,
local logins, ssh logins, and all other services which are configured with
pam_systemd. So it can't really inherit cron-specific settings, for example.

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.


> - 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.

But otherwise it's completely independent: it has its own PAM session, it
is not a child of crond, it is not a parent of crond either, and it does
not manage crond's processes – just sits there in background.


> - does the line I added to access.conf makes sense at all ?
>

Yes – if you want the user to have access to systemd --user, then your PAM
configuration must authorize the "systemd-user" service.

I would probably recommend always listing all three (cron, crond,
systemd-user) because essentially they provide very similar functions,
especially with linger active.

I also noticed that if the user gets lingered there is no such error
> message (which makes me think about the creation of the crond session
> through the systemd --user instance running a job)
>

Linger means the --user instance starts on boot (without waiting for a
systemd "user session" to trigger it) and runs forever. So most likely the
message also shows up only once at boot time.


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