Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Fri, May 04, 2018 at 18:28:36 +0200, Michael Biebl wrote:
> Use a drop-in config as described in the Arch wiki:
> 
> For user sessions to work correctly, an exception needs to be added for
> systemd-logind:
> 
> /etc/systemd/system/systemd-logind.service.d/hidepid.conf containing
> 
> [Service]
> SupplementaryGroups=proc

Odd, I thought I had created exactly that file (but named override.conf
and with "adm") via "systemctl edit systemd-logind", and got this error:
  Service has more than one ExecStart= setting

But it's working fine now and I do get a session.

> Well, I think granting read access to the syslog files (and the journal
> fwiw) as a side effect of granting read access to /proc makes group adm
> a poor choice. Those should be treated separately.
> 
> A dedicated "proc" group, as the Arch wiki suggests, makes much more
> sense to me.

Access to /proc isn't really a side-effect if 'adm' is for "system
monitoring/security".  Though in practice it does just seem to be used
for log access.

I can't really ask you to add "SupplementaryGroups=proc" when the group
doesn't exist by default.  Of course, anyone enabling hidepid can do it
either way, once they figure out what's going on.  The systemd overrides
make it pretty convenient (e.g., I don't have to maintain an entire copy
of the service file with one extra line).

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Biebl]

Am 04.05.2018 um 18:24 schrieb Michael Gold:
> On Fri, May 04, 2018 at 18:02:09 +0200, Michael Biebl wrote:
>> I guess you have two options here:
>> Either drop gid=4 from your mount flags or you add
>> SupplementaryGroups=adm to systemd-logind.service
> 
> I haven't figured out how to override that .service file locally yet,
> but I'm trying to add SupplementaryGroups=adm.

Use a drop-in config as described in the Arch wiki:

For user sessions to work correctly, an exception needs to be added for
systemd-logind:

/etc/systemd/system/systemd-logind.service.d/hidepid.conf containing

[Service]
SupplementaryGroups=proc

> If I just drop 'gid=4' I won't be able to use "pidin aux" myself.
> 
>> Why adm is a suitable group for that purpose is not clear to me, but
>> that's besides the point.
>> https://wiki.archlinux.org/index.php/Security#hidepid suggests to use a
>> dedicated group like proc which makes more sense to me.
> 
> Kind of, but that's not a standard Debian group.  adm is, and does make
> sense based on the documentation (also note that johnw independently had
> the same idea):
>   https://wiki.debian.org/SystemGroups
>   "adm: Group adm is used for system monitoring tasks. Members of this
>group can read many log files in /var/log, …
>staff: Allows users to add local modifications … Compare with group
>'adm', which is more related to monitoring/security."
> 

Well, I think granting read access to the syslog files (and the journal
fwiw) as a side effect of granting read access to /proc makes group adm
a poor choice. Those should be treated separately.

A dedicated "proc" group, as the Arch wiki suggests, makes much more
sense to me.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Fri, May 04, 2018 at 18:02:09 +0200, Michael Biebl wrote:
> I guess you have two options here:
> Either drop gid=4 from your mount flags or you add
> SupplementaryGroups=adm to systemd-logind.service

I haven't figured out how to override that .service file locally yet,
but I'm trying to add SupplementaryGroups=adm.

If I just drop 'gid=4' I won't be able to use "pidin aux" myself.

> Why adm is a suitable group for that purpose is not clear to me, but
> that's besides the point.
> https://wiki.archlinux.org/index.php/Security#hidepid suggests to use a
> dedicated group like proc which makes more sense to me.

Kind of, but that's not a standard Debian group.  adm is, and does make
sense based on the documentation (also note that johnw independently had
the same idea):
https://wiki.debian.org/SystemGroups
"adm: Group adm is used for system monitoring tasks. Members of this
 group can read many log files in /var/log, …
 staff: Allows users to add local modifications … Compare with group
 'adm', which is more related to monitoring/security."

> Anyway, this really seems to simply be a local (mis)configuration issue.

You're right it's a local problem--though not a reasonably foreseeable,
noticeable, or easily debuggable consequence of 'hidepid'.  If you were
willing to add "SupplementaryGroups=adm" to the shipped file, that would
be helpful and I think reasonable based on the stated purpose of 'adm'.
I'm having trouble thinking of a "proper" way for systemd to handle it
while Debian ships with hidepid disabled.

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Biebl]

Control: forcemerge 892585 -1
Am 04.05.2018 um 17:02 schrieb Michael Biebl:
> Am 03.05.2018 um 23:56 schrieb Michael Gold:
>> On Thu, May 03, 2018 at 23:42:34 +0200, Michael Biebl wrote:
>>> Am 03.05.2018 um 23:12 schrieb Michael Gold:
 Is this problem already tracked?
>>> I'd say this is a duplicate of #892585
>>
>> Agreed.
> 
> That bug report mentioned, that dropping gid= was sufficient for him to
> fix the issue.

I guess you have two options here:
Either drop gid=4 from your mount flags or you add
SupplementaryGroups=adm to systemd-logind.service

Why adm is a suitable group for that purpose is not clear to me, but
that's besides the point.
https://wiki.archlinux.org/index.php/Security#hidepid suggests to use a
dedicated group like proc which makes more sense to me.

Anyway, this really seems to simply be a local (mis)configuration issue.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Biebl]

Am 03.05.2018 um 23:56 schrieb Michael Gold:
> On Thu, May 03, 2018 at 23:42:34 +0200, Michael Biebl wrote:
>> Am 03.05.2018 um 23:12 schrieb Michael Gold:
>>> Is this problem already tracked?
>> I'd say this is a duplicate of #892585
> 
> Agreed.  I think there should be a wishlist item requesting that the
> failure be more obvious.  Shall I file one, or just repurpose this one?

I think such a wishlist bug should be filed upstream.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Thu, May 03, 2018 at 23:25:05 +0200, Michael Biebl wrote:
> Well, logind is running as root, but the the service file is locked down
> considerably:
> 
> CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL
> CAP_CHOWN CAP_KILL CAP_DAC_REA
> MemoryDenyWriteExecute=yes
> RestrictRealtime=yes
> RestrictNamespaces=yes
> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module
> @obsolete @raw-io @reboot @swap
> SystemCallArchitectures=native
> LockPersonality=yes
> IPAddressDeny=any
> FileDescriptorStoreMax=512
> 
> You will probably have to tweak those settings yourself, if you want to
> continue to use hidepid

Looking at the Linux code, neither uid 0 or gid 0 is actually special-
cased [fs/proc/base.c]:
static bool has_pid_permissions(struct pid_namespace *pid,
 struct task_struct *task,
 int hide_pid_min)
{
if (pid->hide_pid < hide_pid_min)
return true;
if (in_group_p(pid->pid_gid))
return true;
return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
}

So I guess it's always just looked like root had special access (e.g.,
"ps aux" works fine as uid=gid=0 with no supplementary groups), based on
that ptrace permission which logind probably lacks.

I found the file you're quoting from in /lib/systemd/system/.  What's
the recommended way to do local changes?  Copy to /etc/systemd/system/
and edit?

This failure is really obscure.  Perhaps logind should try to open
/proc/1 when it hits this case, and log an explicit message about
hidepid if it gets ENOENT there.

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Thu, May 03, 2018 at 23:42:34 +0200, Michael Biebl wrote:
> Am 03.05.2018 um 23:12 schrieb Michael Gold:
> > Is this problem already tracked?
> I'd say this is a duplicate of #892585

Agreed.  I think there should be a wishlist item requesting that the
failure be more obvious.  Shall I file one, or just repurpose this one?

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Biebl]

Am 03.05.2018 um 23:12 schrieb Michael Gold:
> retitle 897654 libpam-systemd: hidepid causes "Failed to create session: No 
> such process"
> thanks
> 
> On Thu, May 03, 2018 at 22:53:34 +0200, Michael Biebl wrote:
>> On Thu, 3 May 2018 16:31:53 -0400 Michael Gold  wrote:
>>> Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
>>> pam-systemd initializing
>>> Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
>>> Asking logind to create session: uid=1000 pid=14767 service=lightdm 
>>> type=x11 class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= 
>>> display=:0 remote=no remote_user= remote_host=
>>> Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
>>> Failed to create session: No such process
> ...
>> Are you using hidepid?
> 
> Yes, "proc /proc proc rw,relatime,gid=4,hidepid=2 0 0".  After running
> "mount /proc -o remount,hidepid=0" I logged in on a VT and saw a session
> in the list.
> 
> (I was wrong about this working on the other system.  I'm using the same
> mount options there and also have 0 sessions, at least over ssh.)
> 
> Thanks for the quick response.  Is this problem already tracked?  Any
> idea why it would happen, given that systemd-logind is running as root?

Well, logind is running as root, but the the service file is locked down
considerably:

CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL
CAP_CHOWN CAP_KILL CAP_DAC_REA
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictNamespaces=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module
@obsolete @raw-io @reboot @swap
SystemCallArchitectures=native
LockPersonality=yes
IPAddressDeny=any
FileDescriptorStoreMax=512

You will probably have to tweak those settings yourself, if you want to
continue to use hidepid




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

retitle 897654 libpam-systemd: hidepid causes "Failed to create session: No 
such process"
thanks

On Thu, May 03, 2018 at 22:53:34 +0200, Michael Biebl wrote:
> On Thu, 3 May 2018 16:31:53 -0400 Michael Gold  wrote:
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > pam-systemd initializing
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > Asking logind to create session: uid=1000 pid=14767 service=lightdm 
> > type=x11 class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= 
> > display=:0 remote=no remote_user= remote_host=
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > Failed to create session: No such process
...
> Are you using hidepid?

Yes, "proc /proc proc rw,relatime,gid=4,hidepid=2 0 0".  After running
"mount /proc -o remount,hidepid=0" I logged in on a VT and saw a session
in the list.

(I was wrong about this working on the other system.  I'm using the same
mount options there and also have 0 sessions, at least over ssh.)

Thanks for the quick response.  Is this problem already tracked?  Any
idea why it would happen, given that systemd-logind is running as root?

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Biebl]

On Thu, 3 May 2018 16:31:53 -0400 Michael Gold  wrote:
> Package: libpam-systemd
> Version: 238-4
> Severity: important
> 
> At some point in the past, I was able to shut down my system as a
> non-root user:
>   dbus-send --system --print-reply --dest=org.freedesktop.login1 
> /org/freedesktop/login1 "org.freedesktop.login1.Manager.PowerOff" boolean:true
> 
> But it now gives me this error:
>   Error org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: 
> Interactive authentication required.
> 
> ...probably because I have no loginctl session:
>   $ loginctl
>  SESSIONUID USER SEAT TTY
>   
>   0 sessions listed.
>   $ loginctl session-status
>   Could not get properties: No such process
>   $ strace -f loginctl session-status 2>&1|grep ESRCH
>   $ 
> 
> I log in via lightdm and run an xsession script.  It may have worked in
> the past because I was running ck-launch-session, which apparently no
> longer exists.  pam_systemd also logs "No such process":
>   Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> pam-systemd initializing
>   Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> Asking logind to create session: uid=1000 pid=14767 service=lightdm type=x11 
> class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= display=:0 
> remote=no remote_user= remote_host=
>   Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> Failed to create session: No such process
> 
> The same happens if I log in on a tty rather than X11:
>   Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): 
> pam-systemd initializing
>   Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Asking 
> logind to create session: uid=1000 pid=16106 service=login type=tty 
> class=user desktop= seat= vtnr=0 tty=tty3 display= remote=no remote_user= 
> remote_host=
>   Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Failed 
> to create session: No such process
> 
> logind is running:
>   root 15741  0.0  0.0  64304  5808 ?Ss   11:59   0:00 
> /lib/systemd/systemd-logind
> (I restarted it after the first failure.)
> 
> strace shows that logind fails to open a 'cgroup' file:
>   openat(AT_FDCWD, "/proc/16134/cgroup", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
>   sendmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=..., 
> iov_len=104}, {iov_base="\17\0\0\0No such process\0", iov_len=20}], 
> msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 124

Are you using hidepid?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

Package: libpam-systemd
Version: 238-4
Severity: important

At some point in the past, I was able to shut down my system as a
non-root user:
dbus-send --system --print-reply --dest=org.freedesktop.login1 
/org/freedesktop/login1 "org.freedesktop.login1.Manager.PowerOff" boolean:true

But it now gives me this error:
Error org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: 
Interactive authentication required.

...probably because I have no loginctl session:
$ loginctl
   SESSIONUID USER SEAT TTY

0 sessions listed.
$ loginctl session-status
Could not get properties: No such process
$ strace -f loginctl session-status 2>&1|grep ESRCH
$ 

I log in via lightdm and run an xsession script.  It may have worked in
the past because I was running ck-launch-session, which apparently no
longer exists.  pam_systemd also logs "No such process":
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
pam-systemd initializing
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
Asking logind to create session: uid=1000 pid=14767 service=lightdm type=x11 
class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= display=:0 remote=no 
remote_user= remote_host=
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
Failed to create session: No such process

The same happens if I log in on a tty rather than X11:
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): 
pam-systemd initializing
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Asking 
logind to create session: uid=1000 pid=16106 service=login type=tty class=user 
desktop= seat= vtnr=0 tty=tty3 display= remote=no remote_user= remote_host=
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Failed 
to create session: No such process

logind is running:
root 15741  0.0  0.0  64304  5808 ?Ss   11:59   0:00 
/lib/systemd/systemd-logind
(I restarted it after the first failure.)

strace shows that logind fails to open a 'cgroup' file:
openat(AT_FDCWD, "/proc/16134/cgroup", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
sendmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=..., 
iov_len=104}, {iov_base="\17\0\0\0No such process\0", iov_len=20}], 
msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 124

I'm marking this "important" because, according to the package
description, registering this session is the only purpose of the
package.  But on another system, I do seem to get a valid session.

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-systemd depends on:
ii  dbus1.12.6-2
ii  libc6   2.27-3
ii  libpam-runtime  1.1.8-3.7
ii  libpam0g1.1.8-3.7
ii  systemd 238-4
ii  systemd-sysv238-4

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers