pam_systemd(su:session): Cannot create session: Already occupied by a session

[bl33pbl0p]

Submission type

• Bug report

systemd version the issue has been seen with

systemd 235

Used distribution

Exherbo Linux

In case of bug report: Expected behaviour you didn't see

Session created by su - gets registered correctly under logind and is visible in loginctl's output, as it does for other users when using su - waldo

In case of bug report: Unexpected behaviour you saw

pam_systemd(su:session): Cannot create session: Already occupied by a session
Session is not registered under logind and is not visible in loginctl's output

In case of bug report: Steps to reproduce the problem

su -

[poettering]

Sorry, but "su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session. A new login session has a very well defined, pristine setup, not inheriting anything from any other session, but this is really not the case for "su" uid changes: most of the execution environment is inherited over, in numerous and non-obvious ways, for example MAC contexts, audit contexts, cgroup contexts, namespace contexts, scheduling, timer granularity, …

if you want a full new session, use something like "machinectl login" or "machinectl shell", which will actually get your a fully clean, independent, detach environment, with no hidden process properties leaking from where you call it into it.

logind sessions are mostly bound to the audit session concept, and audit sessions remain unaffected by "su", in fact they are defined to be "sealed off", i.e. in a way that if a process entered a session once, it will always stay with it, and so will its children, i.e. the only way to get a new session is by forking off something off PID 1 (or something similar) that never has been part of a session.

Or to say this differently: the stuff you invoke through "su" will show up just fine in "loginctl", however, it remains part of your original session, you logged in originally. You can verify that by invoking "loginctl status" on the original session's ID (which you can see through echo $XDG_SESSION_ID)

[bl33pbl0p]

Thank you @poettering!

[bl33pbl0p]

@poettering I noticed something strange. The concept behind this was that something part of a session can never create its own, that is as you pointed out, something out of the session (be it PID 1 or something else) must fork it off to create a new session. However, consider this.

delta ~ $ loginctl
SESSION UID USER SEAT TTY
c2 1000 kowalski seat0 tty1
c1 989 gdm seat0 tty7

2 sessions listed.
delta ~ $ su -l kowalski
Password:
delta ~ $ loginctl
SESSION UID USER SEAT TTY
c2 1000 kowalski seat0 tty1
c1 989 gdm seat0 tty7

2 sessions listed.
delta ~ $ su -l kowalski
Password:
delta ~ $ loginctl
SESSION UID USER SEAT TTY
c2 1000 kowalski seat0 tty1
c3 1000 kowalski pts/2
c1 989 gdm seat0 tty7

3 sessions listed.
delta ~ $

The pid of su turns out to be 2530, and then doing a
busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager GetSessionByPID "u" 2530
returns o "/org/freedesktop/login1/session/c3".

I am still not sure why this is not working as intended, it was a child of the process in c2, but it instead created a new session the second time I logged in with su, and since this is a new session, I am sure it inherits no properties from the last one, since it lies now in its own scope unit.

c3 - kowalski (1000)
Since: Sat 2018-01-06 18:18:27 IST; 6min ago
Leader: 2529 (su)
TTY: pts/2
Remote: user kowalski
Service: su; type tty; class user
State: active
Unit: session-c3.scope
├─2529 su -l kowalski
├─2530 -su
├─2753 loginctl session-status c3
└─2754 /usr/host/bin/less

Jan 06 18:18:27 delta systemd[1]: Started Session c3 of user kowalski.

[bl33pbl0p]

and after recursively logging in from c3 using su -l kowalski, it no longer creates a new session on the second invocation as it did in c2.

I login from gdm, a new session is created, I su -l kowalski, no new session, I su -l kowalski again from that su, it creates a new session.

[bl33pbl0p]

@poettering doing a su - does not take me out of the session, but from there when login is run as root, and once a user logs in, it creates a new session again. This should not happen as something cannot possibly create a session when it is already in one.

[bl33pbl0p]

http://dpaste.com/1ZZ39KE.txt relevant paste

[bl33pbl0p]

@poettering Ping! Can this be reopened, it appears things are not working the way they should? The title should probably be changed if that happens to be the case.

[poettering]

@poettering Ping! Can this be reopened, it appears things are not working the way they should? The title should probably be changed if that happens to be the case.

Hmm, what you are describing now appears to be a different issue though, no? i.e. that for some reason logind doesn't properly recognize that your client already is inside a session. Please file a new issue about that.

[ROBERT-MCDOWELL]

@poettering
when I do "loginctl status "
it says
Unknown operation status
Fedora 27 64bits
also is there a way to avoid this behavior "session already running"
knowing that my servers run multiple cron by root sudoing as for example postgres
for hundreds of automated tasks?
thanks

[rugk]

@ROBERT-MCDOWELL Apparently you can just do run loginctl and that works. 😄

Edit: This seems to be equivalent to loginctl list-sessions.

[ROBERT-MCDOWELL]

yeah true, but I'm still trying to create a session for each exec run from a web server side like php