Re: [systemd-devel] Crond session, pam_access and pam_systemd
Hello, [I was off for one week] On 16/10/2020 15:45, Mantas Mikulėnas wrote: If I remember correctly, it's so that the main process would still be able to have pid 1 as its parent, without introducing an intermediate step in the process tree. My understanding after thinking about it would rather be : using PAMName= means that the process the service will execture (let's call it the service process) is to be considerred as PAM-ified even if it's not, which means a PAM session will be created for it. As such a sd-executor like process has to do on its behalf the begining of the PAM calls (the service process may not do any of this call) . And since this executor is replaced (because of exec()) with the actual service process) there is no other choice than to fork/exec before that the sd-pam handler (and thus monitor the pam_session "from the outside") If I'm correct, this would be the reason more than the pid 1 direct parenthood you mentionned. Otherwise, in the standard services (not using PAMName=) case this would work only with the type=forking services, wouldn't it ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Fri, Oct 16, 2020 at 4:13 PM Thomas HUMMEL wrote: > > On 16/10/2020 13:22, Mantas Mikulėnas wrote: > > > But I think you're still confusing the two different kinds of "sessions" > > that exist here. PAM open_session creates a PAM session, which > > eventually *causes* a systemd-logind session to be created, but isn't > > 100% the same thing. > > Yes I probably did. > My undestanding is that a pam session is anything pam modules do between > pam_open_session() and pam_close_session(), which could be things like > write to /var/run/utmp for instance and a systemd-logind session is just > a scope holding all a user processes between his login and logout > Yes, that's right. > > [By the way I don't know how a child process can wait for its parent - > waiting for its parent to send a signal ?] > I haven't actually checked, but I'm guessing it uses prctl(PR_SET_PDEATHSIG). The kernel can automatically send a signal when this is enabled. > No, it's actually started by the systemd system manager itself, because > > user@.service has PAMName= set. It only *appears* to be a child of > > systemd --user, because it is a child of the process which first forked > > sd-pam, then exec'd systemd --user. > > So basically user@.service is a service using PAMName=systemd-user > with an sd-pam pam session handler and which main process (similar to an > ExecStart in a standard service unit) is systemd --user correct ? > Yes. > > Why has it got to work the other way around compared to as service > wainting for its child to finish to call pam_close_session() as you said ? > If I remember correctly, it's so that the main process would still be able to have pid 1 as its parent, without introducing an intermediate step in the process tree. (pid 1 itself cannot call PAM directly because PAM modules can block and they often modify process-wide state, so it has to fork at least once before handling PAM. So if that first child just forked ExecStart as a 2nd-level child process, this would mean a weird difference in behavior between services which use PAMName= and those which don't.) > > > Most tools (sudo, sshd, crond) handle all PAM calls in the parent > > process, just forking your shell or cronjob as a child, then waiting for > > the child to exit before they can call pam_close_session(). Systemd does > > it the other way around – it also forks, but the *child* waits for the > > parent to exit before calling pam_close_session(), whereas the parent > > directly execs the ExecStart command. > > So the second sd-pam you mentionned in your tree above is this handler > mentionnend in the doc I mentionned and waiting for systemd --user to > finish to take proper action when closing the pam session ? > Yes. (Actually in my diagram, I probably shouldn't have labelled the *first* process "sd-pam" -- I think it actually labels itself "sd-executor", as it handles all other environment preparation as well.) > Regarding the following part : > > > systemd-logind > > └ receives CreateSession(uid=1000) > >├ DBus call to systemd: Start(user@1000.service) > >└ DBus call to systemd: StartTransientUnit(session-1234.scope) > > Since you said systemd-logind does not need systemd --user to creates > the session I guess the second job (start transient unit) can be done > without it. So can I conclude that this is just the way systemd-logind > is designed : when instructed to create a session, it also start the > user@.service just for the user to be able to use its own systemd > instance (which in my case of user crontab is not used) ? > Yes. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On 16/10/2020 13:22, Mantas Mikulėnas wrote: But I think you're still confusing the two different kinds of "sessions" that exist here. PAM open_session creates a PAM session, which eventually *causes* a systemd-logind session to be created, but isn't 100% the same thing. Yes I probably did. My undestanding is that a pam session is anything pam modules do between pam_open_session() and pam_close_session(), which could be things like write to /var/run/utmp for instance and a systemd-logind session is just a scope holding all a user processes between his login and logout Not exactly. For cron and sshd, all those PAM functions are called directly by cron or sshd themselves. Ok. That's indeed what I thought initially, being later confused by the sd-pam thing. The sd-pam helper only does this task when systemd pid1 (the service manager) needs to call PAM for a service that has PAMName= set in its unit. https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PAMName= describes sd-pam as a pam session handler when a service unit uses PAMNane= indeed (sorry, I didn't read it before - hence the confusion) [By the way I don't know how a child process can wait for its parent - waiting for its parent to send a signal ?] As far as I could figure out, the entire process works like this: sshd (listener) └ sshd (connection worker) ├ pam_start(sshd, ...) ├ pam_acct_mgmt() │ └ pam_access.so ├ pam_open_session() │ └ pam_systemd.so │ └ DBus call to systemd-logind: CreateSession(service=sshd, uid=1000) ├ fork login shell │ └ /bin/bash └ pam_close_session() Ok. So pam_systemd registers a (systemd-logind) session via dbus to systemd-logind. This session will contain the ssh login shell and so on. systemd-logind └ receives CreateSession(uid=1000) ├ DBus call to systemd: Start(user@1000.service) └ DBus call to systemd: StartTransientUnit(session-1234.scope) See comment at the end. systemd (pid1) └ user@1000.service └ sd-pam ├ pam_start(systemd-user, ...) ├ pam_acct_mgmt() │ └ pam_access.so ├ pam_open_session() ├ fork sd-pam child │ └ sd-pam (waits for parent to exit) │ └ pam_close_session() └ exec systemd --user - such a worker is started by a systemd --user instance No, it's actually started by the systemd system manager itself, because user@.service has PAMName= set. It only *appears* to be a child of systemd --user, because it is a child of the process which first forked sd-pam, then exec'd systemd --user. So basically user@.service is a service using PAMName=systemd-user with an sd-pam pam session handler and which main process (similar to an ExecStart in a standard service unit) is systemd --user correct ? Why has it got to work the other way around compared to as service wainting for its child to finish to call pam_close_session() as you said ? Most tools (sudo, sshd, crond) handle all PAM calls in the parent process, just forking your shell or cronjob as a child, then waiting for the child to exit before they can call pam_close_session(). Systemd does it the other way around – it also forks, but the *child* waits for the parent to exit before calling pam_close_session(), whereas the parent directly execs the ExecStart command. So the second sd-pam you mentionned in your tree above is this handler mentionnend in the doc I mentionned and waiting for systemd --user to finish to take proper action when closing the pam session ? So if you had a basic unit with "ExecStart=/bin/sleep 1h", if it also had User= and PAMName=, then you would see 'sd-pam' as a child of 'sleep 1h'. Ok. user@.service is where the name is configured, but sd-pam is the process which actually calls PAM for that service name. Ok. I don't know why you're seeing the different behavior between crond and sshd. However, a systemd-logind session doesn't actually *need* user@.service (systemd --user), it can be created without. So even if user@.service could not be started due to PAM not authorizing it (or due to some other reason), this will still not prevent pam_systemd from registering the session and creating user-.slice and making it appear in `loginctl`. Ok. Regarding the following part : > systemd-logind > └ receives CreateSession(uid=1000) >├ DBus call to systemd: Start(user@1000.service) >└ DBus call to systemd: StartTransientUnit(session-1234.scope) Since you said systemd-logind does not need systemd --user to creates the session I guess the second job (start transient unit) can be done without it. So can I conclude that this is just the way systemd-logind is designed : when instructed to create a session, it also start the user@.service just for the user to be able to use its own systemd instance (which in my case of user crontab is not used) ? I all of my guesses are correct I still have to figure out the exact problem I had when the user (who had a
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL wrote: > Hello, > > if I try to sum up all of your answers, I come to the following > understanding : > > - sessions are always created via the pam_systemd module > - which is, in my case called (sshd, crond) via the password-auth stack > include > - so crond, through pam_systemd will cause a session to be created > If you specifically mean systemd-logind sessions, yes. But I think you're still confusing the two different kinds of "sessions" that exist here. PAM open_session creates a PAM session, which eventually *causes* a systemd-logind session to be created, but isn't 100% the same thing. > - such session is created via the sd-pam helper responsible for > pam_open_session() and pam_close_session() calls > Not exactly. For cron and sshd, all those PAM functions are called directly by cron or sshd themselves. The sd-pam helper only does this task when systemd pid1 (the service manager) needs to call PAM for a service that has PAMName= set in its unit. As far as I could figure out, the entire process works like this: sshd (listener) └ sshd (connection worker) ├ pam_start(sshd, ...) ├ pam_acct_mgmt() │ └ pam_access.so ├ pam_open_session() │ └ pam_systemd.so │ └ DBus call to systemd-logind: CreateSession(service=sshd, uid=1000) ├ fork login shell │ └ /bin/bash └ pam_close_session() systemd-logind └ receives CreateSession(uid=1000) ├ DBus call to systemd: Start(user@1000.service) └ DBus call to systemd: StartTransientUnit(session-1234.scope) systemd (pid1) └ user@1000.service └ sd-pam ├ pam_start(systemd-user, ...) ├ pam_acct_mgmt() │ └ pam_access.so ├ pam_open_session() ├ fork sd-pam child │ └ sd-pam (waits for parent to exit) │ └ pam_close_session() └ exec systemd --user > - such a worker is started by a systemd --user instance > No, it's actually started by the systemd system manager itself, because user@.service has PAMName= set. It only *appears* to be a child of systemd --user, because it is a child of the process which first forked sd-pam, then exec'd systemd --user. Most tools (sudo, sshd, crond) handle all PAM calls in the parent process, just forking your shell or cronjob as a child, then waiting for the child to exit before they can call pam_close_session(). Systemd does it the other way around – it also forks, but the *child* waits for the parent to exit before calling pam_close_session(), whereas the parent directly execs the ExecStart command. So if you had a basic unit with "ExecStart=/bin/sleep 1h", if it also had User= and PAMName=, then you would see 'sd-pam' as a child of 'sleep 1h'. > - so a user crontab will ultimately cause the use of the already running > systemd --user instance of the user (because his logged in or is > lingered) OR the creation of a systemd --user instance for the purpose > of the crond session creation > Yes, more or less. > > What I still don't quite get is : > > - is it sd-pam or systemd --user or user@.service holding them > which uses the systemd-user pam service name ? > user@.service is where the name is configured, but sd-pam is the process which actually calls PAM for that service name. systemd --user on its own doesn't talk to PAM at all. (See what I wrote above about the sd-pam worker.) > > - my understanding was that pam service name is passed to pam_start() : > in the user crontab case, my guess is that crond does this call with the > crond service name (so pam knows what module stacks to run). > So this would mean something like the user@.service (or sd-pam) > would itself call pam_start(systemd-user, ...) when called by pam_systemd ? > Yes. > > So basically pam_systemd module would trigger another service which > itself would go through pam with the systemd-user service name ? > Yes. > > - again, why is a first ssh login session able to create the user > session without the user having to be listed for systemd-user in > access.conf whereas crond semmes to need it (givent no systemd --user > was previously running in both cases) ? > I don't know why you're seeing the different behavior between crond and sshd. However, a systemd-logind session doesn't actually *need* user@.service (systemd --user), it can be created without. So even if user@.service could not be started due to PAM not authorizing it (or due to some other reason), this will still not prevent pam_systemd from registering the session and creating user-.slice and making it appear in `loginctl`. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
Hello, if I try to sum up all of your answers, I come to the following understanding : - sessions are always created via the pam_systemd module - which is, in my case called (sshd, crond) via the password-auth stack include - so crond, through pam_systemd will cause a session to be created - such session is created via the sd-pam helper responsible for pam_open_session() and pam_close_session() calls - such a worker is started by a systemd --user instance - so a user crontab will ultimately cause the use of the already running systemd --user instance of the user (because his logged in or is lingered) OR the creation of a systemd --user instance for the purpose of the crond session creation What I still don't quite get is : - is it sd-pam or systemd --user or user@.service holding them which uses the systemd-user pam service name ? - my understanding was that pam service name is passed to pam_start() : in the user crontab case, my guess is that crond does this call with the crond service name (so pam knows what module stacks to run). So this would mean something like the user@.service (or sd-pam) would itself call pam_start(systemd-user, ...) when called by pam_systemd ? So basically pam_systemd module would trigger another service which itself would go through pam with the systemd-user service name ? - again, why is a first ssh login session able to create the user session without the user having to be listed for systemd-user in access.conf whereas crond semmes to need it (givent no systemd --user was previously running in both cases) ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On 10/14/20 8:13 PM, Andrei Borzenkov wrote: And both sshd and crond include pam_access in their configuration? Yes, crond has the same session incude of password-auth. Thanks -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
14.10.2020 15:23, Thomas HUMMEL пишет: > > > On 14/10/2020 13:24, Andrei Borzenkov wrote: >> On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL >> wrote: >>> >>> 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@.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 ? >>> >> >> Does PAM configuration for SSH include pam_systemd on your system? > > Yes, via the password-auth include : > > > sshd: > > > session include password-auth > > password-auth: > > > -session optional pam_systemd.so > And both sshd and crond include pam_access in their configuration? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On 14/10/2020 13:24, Andrei Borzenkov wrote: On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL wrote: 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@.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 ? Does PAM configuration for SSH include pam_systemd on your system? Yes, via the password-auth include : sshd: sessioninclude password-auth password-auth: -sessionoptional pam_systemd.so Thanks -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL wrote: > > 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@.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 ? > Does PAM configuration for SSH include pam_systemd on your system? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
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@.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@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote: > 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 ? 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
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@.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@.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@.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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Mon, Oct 12, 2020 at 8:16 PM Thomas HUMMEL wrote: > Thanks for your answer. Still I'm quite confused. > > On 12/10/2020 18:21, Mantas Mikulėnas wrote: > > > > It's a worker process which calls pam_open_session() and > > pam_close_session() on behalf of the user@.service unit. > > Well I may be misunderstanding but this user@.service seems like a > top level (for this user) placeholder for various other services units > and/or scope, among which the init.scope corresponding to the sd-pam and > systemd --user processes). > Yes, but it is *not* a top level for *all* of the user's processes – just for those that are managed through systemctl --user. > > 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@.service, itself, is a system service. > > > > So when you see sd-pam under user@.service, that means it's > > handling the "systemd-user" PAM 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@.service" unit. > > > > 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. > > You mean crond running as the user who has his own crontab does call > pam_open_session() which is defined in the pam_systemd module ? > If this is correct, this has indeed nothing to do with the sd-pam > pam_open_seesion() mentionned above or does it ? > > Yes, they're completely separate PAM instances. > > > > > - 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 > > Yes I understood that. But again I'm not really sure what services or > other units it is supposed to run if I didn't defined user custom > Well, that doesn't mean it shouldn't be started at all – for a few reasons: 1) pam_systemd doesn't know that you don't have any custom units. 2) Even if you don't have any units in ~/.config/systemd, there might be package-installed ones in /usr/lib/systemd/user (such as gpg-agent.socket). 3) systemd --user can also be used for transient units via `systemd-run`. Though, it's true that most of those things are about interactive logins. Actually I kind of wish that pam_systemd would have an option to *only* create the user-.slice cgroup but without starting user@.service... (Arch Linux's /etc/pam.d/crond does not list pam_systemd at all, and it hasn't really created any issues so far.) > services. Is it responsible to run things like the user's UI termnials > for instance ? > Generally no. Even though your login processes belong to a "user session", they are not managed by user@.service in any way. > > > > 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. > > 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. > > > > > - 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@.service is > > triggered by crond opening its PAM session. > > Sorry I don't get it : what service exactly is started ? crond opening > its PAM session does not cause a systemd --user to be instanciated or > It does *if* your distro's /etc/pam.d/cron[d] includes the pam_systemd module. (So on Debian it does, on Arch it doesn't.) > does it ? I thought the only way to have a systemd --user was through > the creation via pam_systemd notifying systemd-logind at a user fist > login (and/or to linger the user) > Yes but that's exactly what happens in cron as well. When crond calls PAM, it does exactly the same thing as when a user logs in interactively – it calls PAM open_session in pretty much the same way as e.g. sshd or console login would. The only difference is the PAM service name (and therefore a different /etc/pam.d config file). -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
Thanks for your answer. Still I'm quite confused. On 12/10/2020 18:21, Mantas Mikulėnas wrote: It's a worker process which calls pam_open_session() and pam_close_session() on behalf of the user@.service unit. Well I may be misunderstanding but this user@.service seems like a top level (for this user) placeholder for various other services units and/or scope, among which the init.scope corresponding to the sd-pam and systemd --user processes). 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 ? So when you see sd-pam under user@.service, that means it's handling the "systemd-user" PAM service. I'm not sure I understood in which cases this PAM service name is used 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. You mean crond running as the user who has his own crontab does call pam_open_session() which is defined in the pam_systemd module ? If this is correct, this has indeed nothing to do with the sd-pam pam_open_seesion() mentionned above or does it ? - 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 Yes I understood that. But again I'm not really sure what services or other units it is supposed to run if I didn't defined user custom services. Is it responsible to run things like the user's UI termnials for instance ? 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. Ok so it's this service (systemd --user) which uses the systemd-user PAM service name ? Passed to the generic sd-pam worker ? Correct ? - 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@.service is triggered by crond opening its PAM session. Sorry I don't get it : what service exactly is started ? crond opening its PAM session does not cause a systemd --user to be instanciated or does it ? I thought the only way to have a systemd --user was through the creation via pam_systemd notifying systemd-logind at a user fist login (and/or to linger the user) Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Mon, Oct 12, 2020 at 5:26 PM Thomas HUMMEL 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@.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@.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@.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@.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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
