Re: [systemd-devel] Crond session, pam_access and pam_systemd

[Thomas HUMMEL]

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

[systemd-devel] Thawing status in a service

[Srijan Sivakumar]

Hello there SMEs,

I'm contributing to glusterfs project and found the service to be in the
state of
*Active: active (running) (thawing) *sometimes.

Now, I tried looking up what is the thawing state but couldn't get anything
concrete on it. Wondering if I could get some help from the actual devs
working on systemd.

Thank you in advance :)
Srijan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Thawing status in a service

[Srijan Sivakumar]

Hi Michal,

Thanks a lot for the information. This is helpful :)

On Wed, Oct 14, 2020 at 4:55 PM Michal Sekletar  wrote:

> On Wed, Oct 14, 2020 at 11:21 AM Srijan Sivakumar 
> wrote:
>
>> Hello there SMEs,
>>
>> I'm contributing to glusterfs project and found the service to be in the
>> state of
>> *Active: active (running) (thawing) *sometimes.
>>
>> Now, I tried looking up what is the thawing state but couldn't get
>> anything concrete on it. Wondering if I could get some help from the actual
>> devs working on systemd.
>>
>
> Hi Srijan,
>
> Thawing state is related to cgroup freezer implementation.
> https://github.com/systemd/systemd/pull/13512
>
> Issue you are referring to is tracked here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1868831
>
> Michal
>
>
>
>> Thank you in advance :)
>> Srijan
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>

-- 
Thanks and Regards,

SRIJAN SIVAKUMAR

Associate Software Engineer

Red Hat





T: +91-9727532362 


TRIED. TESTED. TRUSTED. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Thawing status in a service

[Michal Sekletar]

On Wed, Oct 14, 2020 at 11:21 AM Srijan Sivakumar 
wrote:

> Hello there SMEs,
>
> I'm contributing to glusterfs project and found the service to be in the
> state of
> *Active: active (running) (thawing) *sometimes.
>
> Now, I tried looking up what is the thawing state but couldn't get
> anything concrete on it. Wondering if I could get some help from the actual
> devs working on systemd.
>

Hi Srijan,

Thawing state is related to cgroup freezer implementation.
https://github.com/systemd/systemd/pull/13512

Issue you are referring to is tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=1868831

Michal



> Thank you in advance :)
> Srijan
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
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

[Andrei Borzenkov]

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

[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:


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

[Andrei Borzenkov]

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