[systemd-devel] Crond session, pam_access and pam_systemd
Thomas HUMMEL
thomas.hummel at pasteur.fr
Wed Oct 14 08:42:33 UTC 2020
Hello,
thanks for your answer. It's getting clearer.
Still : why would the user crond runs on behalf of needs to be allowed
in access.conf to access the systemd-user service ?
My understanding is that the user@<uid>.service creation needs this
service type (or just the systemd --user creation ?) such a rule in
access.conf is not needed for let's say a ssh login first session ?
Thanks for your help
--
Thomas HUMMEL
On 13/10/2020 20:05, Simon McVittie wrote:
> On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote:
>> Ok, so for instance, on my debian, when I see:
>>
>>> user at 1000.service
>> │ │ ├─gvfs-goa-volume-monitor.service
>> │ │ │ └─1480 /usr/lib/gvfs/gvfs-goa-volume-monitor
>> │ │ ├─gvfs-daemon.service
>> │ │ │ ├─1323 /usr/lib/gvfs/gvfsd
>> │ │ │ ├─1328 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
>> │ │ │ └─1488 /usr/lib/gvfs/gvfsd-trash --spawner :1.19
>> /org/gtk/gvfs/exec_spaw
>> │ │ ├─gvfs-udisks2-volume-monitor.service
>> │ │ │ └─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
>> │ │ ├─xfce4-notifyd.service
>> │ │ │ └─1355 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd
>>
>> those services jobs are started by the systemd --user in this user init
>> scope, correct ?
>
> Yes. In many cases they're started on-demand (for example because
> something talks to them over D-Bus) rather than being started "eagerly".
>
>> My understanding now after your explanation is that crond, in the case of a
>> user crontab and pam_systemd in the crond stack, will create a session and
>> thus instanciate a systemd --user if not already present (like in the
>> lingered case)
>
> Yes. If uid 1000 is already logged in or is flagged for lingering,
> and a cron job for uid 1000 starts, the cron job will reuse their
> pre-existing systemd --user. If uid 1000 does not already have a
> systemd --user, crond's PAM stack will result in a systemd --user being
> started before the cron job, and stopped after the cron job.
>
>> Do you confirm that, in the case of crond this systemd --user is useless ?
>
> It might be useful, it might be useless. It depends what's in your
> cron jobs.
>
> For example, if you have a cron job that uses GLib to act on SMB shares or
> trashed files or anything like that, then it will need gvfs-daemon.service
> (just like the fragment of a process tree you quoted above) to be able
> to access smb:// or trash:// locations.
>
> smcv
>
More information about the systemd-devel
mailing list