Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Tue, 28 Aug 2012, Colin Guthrie wrote: > 'Twas brillig, and Colin Guthrie at 28/08/12 13:10 did gyre and gimble: > > gdm, but it's nature will register sessions with type=x11 and login with > > type=tty - that's the only reason I suggested gdm as a basis here.. > > arguably it would make more sense to tweak login (or perhaps agetty as > > it already has autologin options etc?) to do this task. > > gdm, _by_ it's nature If you want to be even more accurate: "gdm, by _its_ nature..." "it's" is a contraction of "it is", whereas "its" is a possessive. Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
'Twas brillig, and Colin Guthrie at 28/08/12 13:10 did gyre and gimble: > gdm, but it's nature will register sessions with type=x11 and login with > type=tty - that's the only reason I suggested gdm as a basis here.. > arguably it would make more sense to tweak login (or perhaps agetty as > it already has autologin options etc?) to do this task. gdm, _by_ it's nature -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
'Twas brillig, and Mike Kazantsev at 28/08/12 00:55 did gyre and gimble: > On Tue, 28 Aug 2012 00:32:47 +0100 > Colin Guthrie wrote: > >> >> It's not really as simple as that these days. In order to do things >> cleanly (and from what I understand the CK way was certainly far from >> clean), you really need to use some kind of login agent. Typically this >> would be the job of the DM, but as you are not using one, it's obviously >> not going to work. >> >> So in theory you need to spawn something that acts as a proper login >> agent, has a real PAM conversation and then starts X for you. That's the >> only real way to do the proper user registration (for the simply fact >> that it's not really possible to start a session from a session. >> > ... >> >> Looking forward a simple "autologin" system could get around this. e.g. >> gdm has autologin support. Say it was modified to take the autologin >> user as an argument. You could have a small setuid binary wrapper that >> started gdm for you and passes your user as the autologin user when it >> execs the main gdm process. This would mean all the proper PAM >> conversations happen as expected and everything should be fine. >> >> I only use gdm as an example here as it's got (AFAIUI) good PAM code. A >> standalone autologin system that does PAM well would be fine too (tho' I >> believe it's quite easy to write bad PAM code...) >> > > Just to be clear, there's nothing wrong with "login" establishing the > PAM session and doing startx without changing vt from there, right? Nothing too wrong. As highlighted by the patch to startx I linked, this is indeed how I do it. The only "issue" with it is that a "loginctl show-session n" will show: Type=tty rather than: Type=x11 (NB: I'm not sure if we'll see a Type=wayland in the future or if "x11" should really just be a generic "graphical" term instead?) This doesn't necessarily have a huge bearing right now, but because this is useful metadata it may start to get used more in the future. If/when this becomes a problem, then the "fuller" solution of some real pam+autologin type agent thing is probably the way to go. > Wanted to ask, because it seem to me that gdm with autologin seem to be > unnecessary if just startx works, and OP seemed to be logging into a > text vt explicitly anyway, so I can assume gdm does something more > (PAM-wise?) than login(1) does? Not specifically, it's more the metadata about the session type that might be useful data to some higher level processes as mentioned above. gdm, but it's nature will register sessions with type=x11 and login with type=tty - that's the only reason I suggested gdm as a basis here.. arguably it would make more sense to tweak login (or perhaps agetty as it already has autologin options etc?) to do this task. HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Tue, 28 Aug 2012 00:32:47 +0100 Colin Guthrie wrote: > > It's not really as simple as that these days. In order to do things > cleanly (and from what I understand the CK way was certainly far from > clean), you really need to use some kind of login agent. Typically this > would be the job of the DM, but as you are not using one, it's obviously > not going to work. > > So in theory you need to spawn something that acts as a proper login > agent, has a real PAM conversation and then starts X for you. That's the > only real way to do the proper user registration (for the simply fact > that it's not really possible to start a session from a session. > ... > > Looking forward a simple "autologin" system could get around this. e.g. > gdm has autologin support. Say it was modified to take the autologin > user as an argument. You could have a small setuid binary wrapper that > started gdm for you and passes your user as the autologin user when it > execs the main gdm process. This would mean all the proper PAM > conversations happen as expected and everything should be fine. > > I only use gdm as an example here as it's got (AFAIUI) good PAM code. A > standalone autologin system that does PAM well would be fine too (tho' I > believe it's quite easy to write bad PAM code...) > Just to be clear, there's nothing wrong with "login" establishing the PAM session and doing startx without changing vt from there, right? Wanted to ask, because it seem to me that gdm with autologin seem to be unnecessary if just startx works, and OP seemed to be logging into a text vt explicitly anyway, so I can assume gdm does something more (PAM-wise?) than login(1) does? -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
'Twas brillig, and Alan Stern at 27/08/12 16:53 did gyre and gimble: > On Mon, 27 Aug 2012, Dave Reisner wrote: > You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 >>> >>> That's a reasonable workaround, but it's not a real fix. >> >> Why isn't it a real fix? It's simply different semantics from >> consolekit. If you want this done automatically, it's trivial to write >> your own ~/.xserverrc which does the VT detection and passes it to X as >> an argument: >> >> https://gist.github.com/3489325 > > I meant that it shouldn't be necessary to tell X to run on the same tty > as the original login session. X should be able to pick whichever tty > it wants (or is told), and that information should get propagated to > systemd. This has been discussed on this list a while back (I think started by me). It's not really as simple as that these days. In order to do things cleanly (and from what I understand the CK way was certainly far from clean), you really need to use some kind of login agent. Typically this would be the job of the DM, but as you are not using one, it's obviously not going to work. So in theory you need to spawn something that acts as a proper login agent, has a real PAM conversation and then starts X for you. That's the only real way to do the proper user registration (for the simply fact that it's not really possible to start a session from a session. > The lack of propagation is a bug, and telling X explicitly what tty to > use doesn't fix it. The primary problem is that logind doesn't know that your session is active. As you change vt the session you do have listed in loginctl becomes inactive and thus various ACLs are removed form you user. It was my understanding that startx in Fedora was going to be patched to work. I patched it in Mageia here: http://svnweb.mageia.org/packages/cauldron/xinit/current/SOURCES/xinit-1.3.2-use-current-vt.patch?revision=229253&view=markup >>> Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware >>> of both the test-mode and X session whereas systemd isn't: >> >> That's unfortunate. I doubt anyone on this list cares about CK in any >> real way. logind is the "way forward". > ... >> Presumably, this only works because you launch X with ck-launch-session >> and pam_ck_connector somewhere in your PAM login stack. I don't know > > Indeed: > > $ grep pam_ck_connector /etc/pam.d/* > /etc/pam.d/login:-session optional pam_ck_connector.so > > And ps says: > > stern 1740 1723 0 10:36 tty1 00:00:00 xinit /etc/X11/xinit/xinitrc > -- /usr/bin/X vt01 -auth /home/stern/.serverauth.1723 > root 1741 1740 7 10:36 ?00:05:22 /usr/bin/X :0 vt01 -auth > /home/stern/.serverauth.1723 > stern 1746 1740 0 10:36 ?00:00:00 /usr/bin/ck-xinit-session > /usr/bin/ssh-agent /home/stern/.Xclients Yup, console-kit had two ways to "start a session", via the pam connector or via the ck-launch*/ck-xinit* stuff. Sadly a "consolekit session" is really quite half-hearted and didn't really track user processes properly. With systemd's cgroup support user processes are properly tracked which gives a lot more control, but sadly it comes at the expense of a ck-launch*/ck-xinit replacement. This means you *have* to use PAM, which means that a text login session cannot spawn a 2nd session which, in turn, means the best way is to simply keep the current session "active" which means reusing the current VT for X. Looking forward a simple "autologin" system could get around this. e.g. gdm has autologin support. Say it was modified to take the autologin user as an argument. You could have a small setuid binary wrapper that started gdm for you and passes your user as the autologin user when it execs the main gdm process. This would mean all the proper PAM conversations happen as expected and everything should be fine. I only use gdm as an example here as it's got (AFAIUI) good PAM code. A standalone autologin system that does PAM well would be fine too (tho' I believe it's quite easy to write bad PAM code...) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Mon, 27 Aug 2012, Dave Reisner wrote: > > > You'll need to start X on the same VT that you logged in on. If it's > > > tty1, then: > > > > > > startx -- vt01 > > > > That's a reasonable workaround, but it's not a real fix. > > Why isn't it a real fix? It's simply different semantics from > consolekit. If you want this done automatically, it's trivial to write > your own ~/.xserverrc which does the VT detection and passes it to X as > an argument: > > https://gist.github.com/3489325 I meant that it shouldn't be necessary to tell X to run on the same tty as the original login session. X should be able to pick whichever tty it wants (or is told), and that information should get propagated to systemd. The lack of propagation is a bug, and telling X explicitly what tty to use doesn't fix it. > > Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware > > of both the test-mode and X session whereas systemd isn't: > > That's unfortunate. I doubt anyone on this list cares about CK in any > real way. logind is the "way forward". ... > Presumably, this only works because you launch X with ck-launch-session > and pam_ck_connector somewhere in your PAM login stack. I don't know Indeed: $ grep pam_ck_connector /etc/pam.d/* /etc/pam.d/login:-session optional pam_ck_connector.so And ps says: stern 1740 1723 0 10:36 tty1 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X vt01 -auth /home/stern/.serverauth.1723 root 1741 1740 7 10:36 ?00:05:22 /usr/bin/X :0 vt01 -auth /home/stern/.serverauth.1723 stern 1746 1740 0 10:36 ?00:00:00 /usr/bin/ck-xinit-session /usr/bin/ssh-agent /home/stern/.Xclients > exactly how CK works, but it's my understanding that logind requires a > process running as root to register a new session (on the new tty) if it > is to be authenticated for at_console privileges. > > Now perhaps ConsoleKit is old hat and nobody cares about it any more. > > I haven't tried doing this under a more recent version of Fedora. Is > > there any reason to think it would work any better? > > Well, the startx behavior I showed you will continue to work. I'd > suspect that a newer version of Fedora might not have consolekit at all. Hmmm. Maybe the best thing to do is wait until I install a new version of Fedora (I'm waiting for the official release of 18) and then see what the story is. Thanks for your help, Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Mon, Aug 27, 2012 at 10:32:43AM -0400, Alan Stern wrote: > On Sun, 26 Aug 2012, Dave Reisner wrote: > > > On Fri, Aug 24, 2012 at 12:17:08PM -0400, Alan Stern wrote: > > > I need some help with a problem. > > > > > > I'm currently using Fedora 16, but without a display manager. I log > > > into a text-mode VT (usually tty1) and run startx manually. The > > > display uses tty7 and works fine. > > > > > > But systemd isn't aware of it, or at least, isn't aware that my login > > > session now owns tty7. For example, the devices labelled with the > > > "uaccess" tag have their ACLs adjusted so that I can't use them in the > > > graphical environment. (When I switch back to a text-mode VT they work > > > fine.) > > > > > > I'm not sure who to blame for this: systemd, dbus, or myself. Still, > > > it seems like this _ought_ to work okay. > > > > > > Can anybody help? > > > > > > Alan Stern > > > > > > > You'll need to start X on the same VT that you logged in on. If it's > > tty1, then: > > > > startx -- vt01 > > That's a reasonable workaround, but it's not a real fix. Why isn't it a real fix? It's simply different semantics from consolekit. If you want this done automatically, it's trivial to write your own ~/.xserverrc which does the VT detection and passes it to X as an argument: https://gist.github.com/3489325 > Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware > of both the test-mode and X session whereas systemd isn't: That's unfortunate. I doubt anyone on this list cares about CK in any real way. logind is the "way forward". > [stern@iolanthe ~]$ ck-list-sessions > Session1: > unix-user = '2102' > realname = 'Alan Stern' > seat = 'Seat1' > session-type = '' > active = FALSE > x11-display = '' > x11-display-device = '' > display-device = '/dev/tty1' > remote-host-name = '' > is-local = TRUE > on-since = '2012-08-27T13:52:33.245828Z' > login-session-id = '1' > idle-since-hint = '2012-08-27T13:53:04.012294Z' > Session2: > unix-user = '2102' > realname = 'Alan Stern' > seat = 'Seat1' > session-type = '' > active = TRUE > x11-display = ':0' > x11-display-device = '/dev/tty7' > display-device = '' > remote-host-name = '' > is-local = TRUE > on-since = '2012-08-27T13:52:37.086051Z' > login-session-id = '1' Presumably, this only works because you launch X with ck-launch-session and pam_ck_connector somewhere in your PAM login stack. I don't know exactly how CK works, but it's my understanding that logind requires a process running as root to register a new session (on the new tty) if it is to be authenticated for at_console privileges. > [stern@iolanthe ~]$ systemd-loginctl list-sessions >SESSIONUID USER SEAT > 1 2102 sternseat0 > > 1 sessions listed. > [stern@iolanthe ~]$ systemd-loginctl show-session 1 > Id=1 > Name=stern > Timestamp=Mon, 27 Aug 2012 09:52:32 -0400 > TimestampMonotonic=100394935 > ControlGroupPath=/user/stern/1 > VTNr=1 > TTY=tty1 > Remote=no > Service=login > Leader=992 > Audit=1 > Type=tty > Active=no > KillProcesses=no > IdleHint=yes > IdleSinceHint=3 > IdleSinceHintMonotonic=0 > > > Evidently information is getting sent to (or by) ConsoleKit but not to > systemd, or else the information does get sent to systemd and systemd > ignores it. Either way, this is a bug (although I can't tell where). I can't speak for Lennart and Kay, but I'm pretty sure they'll tell you that this is working as intended. > Now perhaps ConsoleKit is old hat and nobody cares about it any more. > I haven't tried doing this under a more recent version of Fedora. Is > there any reason to think it would work any better? Well, the startx behavior I showed you will continue to work. I'd suspect that a newer version of Fedora might not have consolekit at all. > Alan Stern > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Sun, 26 Aug 2012, Dave Reisner wrote: > On Fri, Aug 24, 2012 at 12:17:08PM -0400, Alan Stern wrote: > > I need some help with a problem. > > > > I'm currently using Fedora 16, but without a display manager. I log > > into a text-mode VT (usually tty1) and run startx manually. The > > display uses tty7 and works fine. > > > > But systemd isn't aware of it, or at least, isn't aware that my login > > session now owns tty7. For example, the devices labelled with the > > "uaccess" tag have their ACLs adjusted so that I can't use them in the > > graphical environment. (When I switch back to a text-mode VT they work > > fine.) > > > > I'm not sure who to blame for this: systemd, dbus, or myself. Still, > > it seems like this _ought_ to work okay. > > > > Can anybody help? > > > > Alan Stern > > > > You'll need to start X on the same VT that you logged in on. If it's > tty1, then: > > startx -- vt01 That's a reasonable workaround, but it's not a real fix. Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware of both the test-mode and X session whereas systemd isn't: [stern@iolanthe ~]$ ck-list-sessions Session1: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/tty1' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:33.245828Z' login-session-id = '1' idle-since-hint = '2012-08-27T13:53:04.012294Z' Session2: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:37.086051Z' login-session-id = '1' [stern@iolanthe ~]$ systemd-loginctl list-sessions SESSIONUID USER SEAT 1 2102 sternseat0 1 sessions listed. [stern@iolanthe ~]$ systemd-loginctl show-session 1 Id=1 Name=stern Timestamp=Mon, 27 Aug 2012 09:52:32 -0400 TimestampMonotonic=100394935 ControlGroupPath=/user/stern/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=992 Audit=1 Type=tty Active=no KillProcesses=no IdleHint=yes IdleSinceHint=3 IdleSinceHintMonotonic=0 Evidently information is getting sent to (or by) ConsoleKit but not to systemd, or else the information does get sent to systemd and systemd ignores it. Either way, this is a bug (although I can't tell where). Now perhaps ConsoleKit is old hat and nobody cares about it any more. I haven't tried doing this under a more recent version of Fedora. Is there any reason to think it would work any better? Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Fri, Aug 24, 2012 at 12:17:08PM -0400, Alan Stern wrote: > I need some help with a problem. > > I'm currently using Fedora 16, but without a display manager. I log > into a text-mode VT (usually tty1) and run startx manually. The > display uses tty7 and works fine. > > But systemd isn't aware of it, or at least, isn't aware that my login > session now owns tty7. For example, the devices labelled with the > "uaccess" tag have their ACLs adjusted so that I can't use them in the > graphical environment. (When I switch back to a text-mode VT they work > fine.) > > I'm not sure who to blame for this: systemd, dbus, or myself. Still, > it seems like this _ought_ to work okay. > > Can anybody help? > > Alan Stern > You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
