Hello, thanks again for your answer (and for your patience ;-))
On 12/10/2020 19:48, Mantas Mikulėnas wrote:
Yes, but it is *not* a top level for *all* of the user's processes –
just for those that are managed through systemctl --user.
Ok, so for instance, on my debian, when I see:
user@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 ?
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.
Ok it is a system service but why would other system services use the
sd-pam helper in the init scope inside of a user 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.
But in a regular ssh session, this service gets started without the need
for the user to have (in access.conf) access to systemd-user pam service.
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)
Do you confirm that, in the case of crond this systemd --user is useless
? It is just created because it is the generic way a session (and side
user@<uid>.service) is created ?
It correct, I still don't get why the user would need to be explcitly
(in access.conf) allowed to access systemd-user pam service while it's
not needed if it had ssh'd
Yes, they're completely separate PAM instances.
Ok but again, the crond pam session has nothing to do with sd-pam or
does it ?
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.
You said above that it was only at the creation of this service ?
Thanks for your help
--
Thomas HUMMEL
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel