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)
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.
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)
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"?
Ah, yes, typo on my side, a loginmanager can cause "Remote=yes". Sorry.
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
Ok, good to know, thanks.