I talked privately to ajax and Jon about this; just filing a bug for good measure. +++ This bug was initially created as a clone of Bug #229172 +++ I've installed FC7test1 on my laptop (a Dell Latitude D600), and gnome-power-manager consistently fails to suspend: Feb 19 02:34:58 example gnome-power-manager: (username) Suspending computer because the lid has been closed on ac power Feb 19 02:34:58 example gnome-power-manager: (username) Permission denied: Not in active session code='30' quark='g-exec-error-quark' Feb 19 02:34:58 example gnome-power-manager: (username) Resuming computer Feb 19 02:34:58 example gnome-power-manager: (username) suspend failed Actual results: Expected results: Additional info: -- Additional comment from ralston on 2007-02-19 02:47 EST -- Additionally, FC6 (what I was running previously) was able to suspend/resume just fine. -- Additional comment from davidz on 2007-02-19 10:59 EST -- Do you login via gdm? -- Additional comment from ralston on 2007-02-19 13:09 EST -- Nope. I boot in runlevel 3, then login on the console and run "startx". -- Additional comment from davidz on 2007-02-19 13:20 EST -- Yeah, we need to teach login(1) about poking ConsoleKit - see bug 228110 for details. I'm assigning this to ConsoleKit for the time being as I'm working on a patch for this. If you login via gdm things will work so you can do that for now until this is fixed. Thanks. -- Additional comment from ralston on 2007-02-19 15:09 EST -- Hmmm, interesting stuff (about ConsoleKit and what not). I'll use gdm for the time being. -- Additional comment from davidz on 2007-02-19 23:32 EST -- Hi Karel, As you know one of the features we're doing for Fedora 7 is fast user switching. http://fedoraproject.org/wiki/Desktop/FastUserSwitching It means we have a new daemon, ConsoleKit, that tracks session activity and announces state changes (session add, remove, active_changed) on D-Bus. This means we can do things like dynamically adding / removing ACL's on device nodes depending on whether a session is active and, in the future, what seat it belongs to when we're going to do multi-seat and other interesting things. ACL management was added to HAL (that now listen for ConsoleKit events) in the hal-0.5.9-0.git200718.fc7 package and I'm aiming to make this completely replace pam_console (and it's short comings) in order to do things mentioned in bug 140853 as well as handling user space devices like gphoto2 cameras and SANE scanners a lot better. So the major change is that login managers now need to register with ConsoleKit otherwise users in such sessions don't get access to device files, nor will they be allowed to invoke non-trivial methods on HAL such as for mounting storage devices and putting the computer to sleep. In gdm we've have had support for this for a while and bug 228110 is tracking all relevant login managers. As such, it would be nice to support login sessions on VT's such that device access and D-Bus calls are granted for console use and also when people are using startx). To enable this I've written a patch for login(1) that achieves this for login sessions on VT's by registering with ConsoleKit! Now, I know /bin/login is highly security sensitive code so I've tried to be careful; the bulk of the code in in a CKConnection class (that is useful for other login managers such as kdm). Btw, the reason for not doing this in a PAM module is spelled out in bug 228110 comment 5. Things about the patch - it makes util-linux depend on dbus; we could dlopen libdbus but I'm not sure it's worth it - D-Bus is now ABI stable and it's a core part of our OS. Anyway, I'm not violently opposed to dlopen() it just seems a bit more fragile. - needs some work on the build system integration for util-linux - ideally I'd like to get this upstream but it sorta depends a bit on when we're ready to declare the OpenSessionWithParameters() and CloseSession() methods on ConsoleKit ABI stable. I'm working this out with Jon (added as Cc) Thanks for considering this. -- Additional comment from davidz on 2007-02-19 23:33 EST -- Created an attachment (id=148400) source code patch -- Additional comment from davidz on 2007-02-19 23:35 EST -- Created an attachment (id=148401) spec file patch -- Additional comment from davidz on 2007-02-19 23:36 EST -- RPM and SRPM for Rawhide here http://people.redhat.com/davidz/util-linux-2.13-0.49.1dze.i386.rpm http://people.redhat.com/davidz/util-linux-2.13-0.49.1dze.src.rpm Karel, sorry, I forgot to reassign to owner. Please see comment 6. Thanks! -- Additional comment from davidz on 2007-02-19 23:41 EST -- (Also, startx don't entirely works with this setup yet. The problem is that the X server allocates a new VT (it can do this only because it's setuid root) so ConsoleKit most probably needs to be poked by the X server such that CK can mark the session as active both when, say, VT1 and VT8 is active. I talked to ajax, our X.org guy, about this on IRC and he's fine with this approach. I'll look into writing a patch for X about this after I've discussed this with Jon. Thanks.) -- Additional comment from pertusus on 2007-02-20 03:23 EST -- (In reply to comment #7) > Created an attachment (id=148400) [edit] > source code patch > Why can't this be done in pam instead? In session? ckc_new and ckc_create_local_session would be called by the session function, then pam_putenv would be used to set the XDG_SESSION_COOKIE environment variable. Why wouldn't that work? -- Additional comment from davidz on 2007-02-20 03:33 EST -- (In reply to comment #11) > Why can't this be done in pam instead? Please see bug 228110 comment 5 why a PAM module in general cannot be used. Thanks. -- Additional comment from davidz on 2007-02-28 00:53 EST -- OK, so we now have a PAM module. So all we need to do is - make util-linux Requires: ConsoleKit-libs - add "session optional pam_ck_connector.so" to /etc/pam.d/login Karel, is this OK with you? If so, can I make this change in pkg cvs once ConsoleKit-libs is in Rawhide? Thanks. -- Additional comment from kzak on 2007-02-28 04:23 EST -- David, cool news. Thanks. Go ahead! -- Additional comment from davidz on 2007-03-03 15:52 EST -- Awesome. I'm now building 2.13-0.50 which should have this change. Thanks! -- Additional comment from ralston on 2007-03-20 15:35 EST -- This still isn't working for me, and I'm up-to-date with Rawhide as of yesterday: $ rpm -q util-linux ConsoleKit util-linux-2.13-0.50.fc7 ConsoleKit-0.1.3-0.git20070301.1.fc7 If I login on the console, run startx, and then attempt to suspend, the error messages are the same: Mar 20 15:26:48 example gnome-power-manager: (username) Suspending computer because the lid has been closed on ac power Mar 20 15:26:48 example gnome-power-manager: (username) Permission denied: Not in active session code='30' quark='g-exec-error-quark' Mar 20 15:26:48 example gnome-power-manager: (username) Resuming computer Mar 20 15:26:48 example gnome-power-manager: (username) suspend failed Something that might be related: when I login on the console now, I consistently receive this error message (before my .bash_profile executes): ** (console-kit-daemon:3492): WARNING **: Couldn't read /proc/3491/environ: Failed to open file '/proc/3491/environ': No such file or directory -- Additional comment from davidz on 2007-03-20 15:56 EST -- This should work with ConsoleKit-0.2.0-2 (hit Rawhide today) otherwise please reopen. Thanks.
I have a patch to xinit but it needs some changes in ConsoleKit - will coordinate with Jon.
*** Bug 234379 has been marked as a duplicate of this bug. ***
Created attachment 151476 [details] updated xinit patch
Created attachment 151478 [details] Proposed spec file changes.
Created attachment 151479 [details] Updated spec file changes Ugh, sorry, forgot the BR.
These patches work for me. OK to commit? Note that ConsoleKit-x11 is a new package that will hit Rawhide tomorrow - see bug 233982 for details. (The xinit patch needs some massaging before it's ready for upstream, mainly just build system stuff to be able to build without ConsoleKit. I'll file it separately on the upstream Xorg bugzilla at fd.o)
Created attachment 151481 [details] Updated spec file changes Also, we need a bit more BR since we autoreconf..
Got the go-ahead from ajax and krh on IRC; this is in xorg-x11-xinit-1.0.2-18.fc7. (also had to add BR: xorg-x11-util-macros and move man pages references in the spec file from 1x to 1)
I'm still seeing this in Raw Hide, with xorg-x11-xinit-1.0.2-18.fc7. Opening a terminal window and running ck-list-sessions gives me: Session1: uid = '2510' realname = 'Nalin Dahyabhai' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/tty1' remote-host-name = '' is-local = TRUE on-since = '2007-04-17T14:45:56Z' idle-since-hint = '2007-04-17T14:47:11Z' The on-since time matches my console login, but 15 minutes passed before I ran "startx" to start a graphical session. If it helps, the $XDG_SESSION_COOKIE value is also an empty string inside of the graphical session. From poking around in /proc, gnome-session has an empty value, while the X server has the correct value. Both are children of xinit.
Nalin, does this work in permissive mode?
Um, yes, yes it does.
OK, the right thing is probably to file a bug against selinux-policy then...
Confirmed; this works in permissive mode just fine. (I've been running in permissive mode for a while, because there are a few policy tweaks I need to make that I keep putting off; I didn't even realize that this was still broken in enforcing mode.)
No please do not file a bug against SELinux policy. It is better to keep this bug and CC me. That way I get the history. James Ralston, please mail me your audit.log and I will take a look at it.
Dan: I appreciate the offer, but the default policy is just fine; I need to tweak it because I've moved the bind chroot from /var/named/chroot to /chroot/named, and configured ntp to use a chroot of /chroot/ntpd. I think that with SELinux, using a dedicated /chroot partition makes more sense than sprinkling chroot areas throughout the filesystem. While this isn't as big of an issue with the "targeted" policy, I think this was particularly noticable at the first SELinux implementation attempt using the "strict" policy, as it was a pain to make sure that SELinux policy permitted the chroot'ed daemons (and any helper applications) to walk down through the filesystem to reach their chroot areas. Creating a separate top-level directory (/chroot) specifically for containing chroot structures should not only simplify SELinux "strict" policy, but make it easier to chroot other daemons: /chroot can be left open, daemons should be allowed into their respective /chroot subdirectory structures, and nothing else should be allowed to descend into any subdirectory of /chroot. This is why I want to roll policy tweaks for /chroot myself; I want to see if that experience makes a compelling argument for isolating chroot structures to a dedicated (and top-level) area of the filesystem.
Ok, I have heard similar talk of a /var/chroot. Which makes total sense to me.