On Mon, Oct 12, 2020 at 5:26 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> 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@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
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
