[solv] systemd-logind: login manager vs tty-login: permission-setting?

Ovion · 2013-08-15 21:52:40

Dear Archers,

I had a little chat recently with someone concerning the use and non-use of a login manager. I was told that the login via tty and the manual starting of the X-Server leads to logind not registering the session as a proper session (can be seen by "Remote=no" in the session properties via "loginctl show-session"), which can cause problems for example concerning NetworkManager due to wrong/missing permissions.

I myself never encountered such problems as I don't use NetworkManager, but I'd like to understand why a [place-login-manager-here].service is treated differently as tty-login.service by logind and what that can change (mabye netctl without root?).

I'd be glad if someone could shed some light on this.

Last edited by Ovion (2013-08-17 06:00:36)

WonderWoofy · 2013-08-15 22:22:28

It shouldn't be. But in order for logind to track the X session, it has to be run on the same TTY as 'startx' was run from. This is now handled correctly in Arch by the default xserverrc. Check out /etc/X11/xinit/xserverrc. This will lead to an "Active=yes" in the output of loginctl show-session <session #>. An active session is required for the things like user shutdown/reboot/suspend/etc. as well as the networkmanager example you mentioned. In other words, the proper PolicyKit stuff is applied.

As far as "Remote=no" that has nothing to do with it. That simply tells you whether you are looged in locally or not. So when I ssh (I actually use mosh, but that is besides the point) into my file server, I get "Remote=yes", but if I were to plug a monitor and keyboard into it, and then log in, I would get "Remote=no". It is really the session being active that will affect the usability of policy based authentication.

Ovion · 2013-08-16 20:52:15

Ok, this makes more sense, especially concerning the naming of the properties. Thanks for the explanation. It seems though, that using a login-manager can cause a "Remote=yes" [Edit: was "=no" originally due to a typing error of mine] interestingly (haven't checked myself and that was no Arch either). Can that be explained because X is originally started on tty7, which means that it is remote-accessing the session on tty1 or something like this?

Last edited by Ovion (2013-08-17 02:38:45)

WonderWoofy · 2013-08-16 22:57:40

What? That doens't make sense. If it says "remote=no" then it is not remote... Did you mean that a login manager can make it "Remote=yes"?

Ovion · 2013-08-17 02:36:16

Ah, yes, typo on my side, a loginmanager can cause "Remote=yes". Sorry.

cfr · 2013-08-17 02:59:35

No, using a login manager will not cause a "Remote=yes". If that's what you see with kdm, something else is going on.

$ loginctl show-session 1
Id=1
Timestamp=Sad 2013-08-17 00:41:24 BST
TimestampMonotonic=98804488
DefaultControlGroup=systemd:/user/1000.user/1.session
VTNr=7
Display=:0
Remote=no
Service=kde
Leader=1590
Audit=1
Type=x11
Class=user
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0

Ovion · 2013-08-17 04:37:48

Ok, good to know, thanks.

Arch Linux

#1 2013-08-15 21:52:40

[solv] systemd-logind: login manager vs tty-login: permission-setting?

#2 2013-08-15 22:22:28

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

#3 2013-08-16 20:52:15

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

#4 2013-08-16 22:57:40

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

#5 2013-08-17 02:36:16

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

#6 2013-08-17 02:59:35

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

#7 2013-08-17 04:37:48

Re: [solv] systemd-logind: login manager vs tty-login: permission-setting?

Board footer