[EN] Automatic logout when changing the target

[bluelupo]

Hi community,

Since a few days you will be automatically logged in a change of the target. Can the behavior of systemd any of you reproduce?

This command I enter on a text console (tty) and then I get logged out:

Code: [Select]

# systemctl isolate multi-user.target

EDIT: opened bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805442

[ayla]

Same behaviour here.

Code: [Select]

systemd:
  Installiert:           227-3
But, I don't understand the problem. Isn't this the expected behaviour?
When I'm logged in on a tty console, I am in the multi-user.target I think? Or am I not?
When I then give the command to isolate this target, shouldn't systemd then logout?
Isolate multi-user.target on graphical surface works and graphical.target on tty also.

greets
ayla

[horo]

Hi,

same behaviour here with systemd version 227-3. But bluelupo is right, this has changed some days (weeks?) ago. Earlier I switched with <ALT><CTRL><F1> to tty1, logged in as root and changed "runlevel" with

Code: [Select]

systemctl iso... multi... and remained logged in on this screen.

Ciao, Martin

[bluelupo]

hi ayla,
I do not believe that this is the expected behavior. If I, for example, from graphical desktop out the CTRL-ALT-F1 press to get to a text console, but am still in graphical.target (formerly init 5). There, for example, want to before a you a change to multi-user.target make (formerly init 3). At this point I'm going to be logged, that is definitely not been the default behavior.
---

In deutsch:

hi ayla,
Ich glaube nicht das dies das erwartete Verhalten ist. Wenn ich z.B. aus grafischen Desktop heraus die Tastenkombination CTRL-ALT-F1 drücke komme ich auf eine Textkonsole, bin aber immer noch im graphical.target (früher init 5). Dort möchte z.B. vor einem d-u einen Wechsel zum multi-user.target machen (früher init 3). An dieser Stelle werde ich jetzt ausgeloggt, das ist definitiv nicht das Standardverhalten gewesen.

[der_bud]

Could it have to do with security changes regarding X and setuid root, see end of my post?

Expected or earlier behavior:
 - a) you start in your desktop environment (running X)
 - b) switch with STRG+ALT+F1 to tty 1 (X still runs, test with STRG+ALT+F7 and back)
 - c) you want to DU without running X so 'systemctl isolate multi-user.target' stops X on F7),
    c1) while you stay logged in on tty1
   (c would be the same as if you 'systemctl stop lightdm [or sddm])

Now c1) doesn't really work as expected/earlier... -> throws you out, relogin necessary.

----

System1 with kdenext, sddm as DM, xserver-xorg-core 2:1.17.3-2, xserver-xorg-legacy 2:1.17.3-2, systemd 227-3

Acting like c) does stop X, logs me out of tty1 and gives me re-login prompt on tty1, I can login as root and work on.
After 'systemctl isolate graphical.target' X is started and lets me re-login in sddm.

 System1, a) user in X,

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         5        117 sddm             seat0
         6       1000 martin           seat0
2 sessions listed.
 System1, b) root in tty1, X still running

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         5        117 sddm             seat0
         6       1000 martin           seat0
         7          0 root             seat0
3 sessions listed.
 System1, c) X stopped, root thrown out and re-logged in

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         8          0 root             seat0
1 session listed.
----

System2, no kdenext (stock debian), lightdm as DM, xserver-xorg-core 2:1.17.3-2, no xserver-xorg-legacy, systemd 227-3

Acting like c) does stop X, logs me out of tty1 and gives me re-login prompt on tty1, I can login as root and work on.
After 'systemctl isolate graphical.target' X is started and lets me re-login in lightdm.

 System2, a) user in X,

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         1       1000 martin            seat0
        c1        105 lightdm           seat0
2 sessions listed.
 System2, b) root in tty1, X running

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         1       1000 martin            seat0
         2          0 root              seat0       
        c1        105 lightdm           seat0
3 sessions listed.
 System2, c) X stopped, root thrown out and re-logged in

Code: [Select]

loginctl list-sessions:
    SESSION        UID USER             SEAT
         3          0 root             seat0
1 session listed.
----

Could it perhaps be a side effect related to changes for xserver, because the topic in irc #debian-next says "Unprivileged Xorg is here! /msg dpkg xorg root" , which gives

/msg dpkg xorg root
From Debian 9 "Stretch" onwards (xorg-server 1.17.3-1), the Xorg server is no longer setuid root, reducing the risk of privilege escalation security problems. This relies on logind and libpam-systemd and moves the logs to ~/.local/share/xorg; use the xserver-xorg-legacy package and see Xwrapper.config(5) if you'd rather a setuid root X.

[ayla]

You're right bluelupo, as I seldom use CTRL-ALT-F1 I forgot that graphical target is still active.
So, when I'm logged in on tty as root I also see no reason to log out when changing "runlevel". I'm root, so what?

[OppaErich]

Hmm, sure this can't be configured somewhere ? I'm using Fedora 21 since it was released and it showed this (annoying) behaviour from day one.

[der_bud]

That would probably match my guess, because fedora has non-setuid xorg since 21 ( https://fedoraproject.org/wiki/Changes/NonSetuidXorg ). But still, I dont know enough about the mechanisms behind the correlation behind runlevel-switching and xorg privileges.

[Ercolinux]

same behavior here, with the irritating + to switch off eth0 interface    (avoided following forum suggestion to stop sddm instead going "init 3")

[melmarker]

can someone please explain why the so called 'init 3' is still needed?

[ayla]

can someone please explain why the so called 'init 3' is still needed?

Shorter than systemctl iso.... or systemctl stop.... ?? 

[melmarker]

@ayla - in general - why? We aren't in the bad old sidux days anymore - and if one has any doubts, ALT-F1 or screen should be sufficient

[paxmark2]

In short in Siduction LXQT with lightdm and systemd 227-3 bug 805442 is replicated and a detached session of tmux is also killed.  This also kill my network using connman and my openvpn session via the killing of tmux.  In an atom netbook also using Siduction LXQT repository but testing under Sparky linux with systemd 227-3 and connman 1.21-1.2 the sddm bug 805442 is not replicated, but network services are killed and error lines displayed after issuing "systemctl isolate multi-user target".


I gave up on systemctl isolate multi-user target in maybe July and went to using systemctl stop lightdm on one system and systemctl stop sddm on another.  This stopped a nagging intermittent crashing of connman on wlan0 or eth0  which was restored either by ifup wlan0 or systemctl start connman.service.  Sometimes stop connman service was needed first.


This was noted on two machines using Siduction LXQT sources, one siduction and the other an atom netbook with testing - Sparkylinux. 


Todays details follow.


On the atom netbook  on testing today after using sytemct isolate multi-user did not log me out of the root console on tty1. What it did do was crash the network (wlan0).    systemctl start connman and ifup wlan0 did not restore network.   


After the command of isolate multi-user target 2 lines were displayed

Code: [Select]

Policykit daemon disconnected from the bus
We are no longer a registered authentication agent

I rebooted  and replicated the same behaviour, unable to apt-get update after systemctl isolate, but was able to prior to issuing the command, However a systemctl stop connman and then a systemctl start connman restored my wlan0. 


That would be a bug for me as the first thing I  usually do after powering on is start a vpn in a root tty1 via openvpn my...blah.ovpn in tmux and detach and then kill x via stopping lightdm or sddm and thenupdate and dist-upgrade -d  in the same tty1 and then restart x.


systemd on testing is systemd 227-2


On a pure siduction LXQT install of siduction the isolate ... command logged out the root tty1 as in bug #805442, the detached tmux session was killed and of course the network went down.   The network was resumed via "double-clutching" i,e. systemctl start, then stop, then systemctl start connman.  I am holding off on the dist-upgrade to systemd 228-1.  connman is 1.30-1 in sid


systemctl stop or start of lighdm or sdd services works flawlessly.


tmux in tty1 being affected via isolate multi-user.target is a bug.

[piper]

Some good reading

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Targets.html

[horo]

Hi,

This behaviour shouldn't be related to the xorg server because if you've already switched to multi-user.target and do again

Code: [Select]

systemctl isolate multi-user.target you will be logged out again. Ok, its annoying but on the other hand it gives you a clean start.

Ciao, Martin