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
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
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.
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
> -
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
-
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.fre
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 allowe
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 understandi
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
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 ?) su
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
>
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@100
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
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
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-
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(syst
16 matches
Mail list logo
