<div dir="ltr"><div dir="ltr">On Mon, Oct 12, 2020 at 5:26 PM Thomas HUMMEL <<a href="mailto:thomas.hummel@pasteur.fr">thomas.hummel@pasteur.fr</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Using systemd-239 on CentOS 8.2 I'm trying to figure out what exactly <br>
happens when a cron "session" is created. In particular, what <br>
corresponds to the following error messages I get while running a user <br>
crontab :<br>
<br>
2020-10-12T14:27:01.031334+02:00 maestro-orbit systemd: <br>
pam_access(systemd-user:account): access denied for user `toto' from <br>
`systemd-user'<br>
<br>
2020-10-12T14:27:01.036959+02:00 maestro-orbit crond[135956]: <br>
pam_systemd(crond:session): Failed to create session: Start job for unit <br>
user@1000.service failed with 'failed'<br>
<br>
- What I'm doing :<br>
<br>
ssh to the host, sudo -u toto, crontab -e, exit<br>
<br>
so when toto's crontab gets executed toto has no running sessions<br>
<br>
- access.conf, for cron, has the line<br>
<br>
+:ALL:cron crond<br>
<br>
- If, I add<br>
<br>
+:toto:systemd-user<br>
<br>
the error messages do not occur anymore.<br>
<br>
My understanding is that for an standard logged-in user, pam_systemd <br>
registers the user sessions to systemd-logind and each logged-in user <br>
has a user slice holding all his session's scopes plus an init scope <br>
holding a user@<uid>.service which in turns holds at least a user <br>
instance of systemd (systemd --user) and "sd-pam".<br>
<br>
So my questions are:<br>
<br>
- what is sd-pam ?<br></blockquote><div><br></div><div>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.)</div><div><br></div><div>So when you see sd-pam under user@<uid>.service, that means it's handling the "systemd-user" PAM service.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- is a crond session different from a user session ?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what pam service name does crond use ?<br></blockquote><div><br></div><div>Either "cron" or "crond", depending on which cron implementation your distro uses. Check which pam.d config file was already included by your distro.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what does the first error message refers to and why does the <br>
systemd-user pam service name get passed ? and by which systemd (system <br>
or user) ?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what is the failing systemd job the second message refers to ? Does <br>
this mean that the crond "session" gets created by the systemd --user <br>
instance (as some gnome apps in other contexts for instance) ?<br></blockquote><div><br></div><div>No, it's mostly the opposite – the starting of user@<uid>.service is triggered by crond opening its PAM session.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- does the line I added to access.conf makes sense at all ?<br></blockquote><div><br></div><div>Yes – if you want the user to have access to systemd --user, then your PAM configuration must authorize the "systemd-user" service.</div><div><br></div><div>I would probably recommend always listing all three (cron, crond, systemd-user) because essentially they provide very similar functions, especially with linger active.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also noticed that if the user gets lingered there is no such error <br>
message (which makes me think about the creation of the crond session <br>
through the systemd --user instance running a job)<br></blockquote><div><br></div><div>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.</div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>