If you're logged in as a user and run su from a terminal and attempt to run a graphical app, you get "No protocol specified" spewed and the app fails to connect to the display. In Xorg.log, there's an audit message AUDIT: date: 2269 Xorg: client 30 rejected from local host (uid=0 gid=0 pid=) This also impacts apps that use consolehelper and thus breaks the ability to start the installer from the livecd.
And running 'xhost +' works around, but seems like the wrong answer :)
This is because we can't create the lock in /var/run/gdm where the xauth cookie is living.
*** Bug 441831 has been marked as a duplicate of this bug. ***
This also affects SSH'ing to other hosts since the X forwarding code in SSH needs to access the xauth cookies.
gdm-2.21.10-0.2008.04.11.1.fc9 seems to have fixed my problems with SSH and "su". Didn't even need to reboot or login/logout.
Rebooting after install new gdm produces unhappiness..... I get a popup that yells at me for trying to login as a privileged user. It then hangs. I have to revert to gdm-2.21.10-0.2008.04.08.4.fc9.i386 to login again. [I can't seem to reopen this.....]
Yeah, the same was reported on IRC, try: http://koji.fedoraproject.org/koji/buildinfo?buildID=45962 Once it's done building.
Yeah..... that works.
good!
*** Bug 442157 has been marked as a duplicate of this bug. ***
*** Bug 442168 has been marked as a duplicate of this bug. ***
As the saying goes "ittttssssss baccckkkkkk" With today's rawhide, this behavior has reappeared. Perms on /var/run/gdm have changed from 1777 to 1775
*** Bug 456516 has been marked as a duplicate of this bug. ***
Yeah, we need a better fix here, either fix the stupid locking in libXau or create per-user subdirectories in /var/run/gdm
Note that some resolution of this is required for Fedora 10 alpha, as otherwise, installs from live images are non-functional.
per user sub directories seems like the right way to go. If the alpha is time crunched, we could just add back the sticky bits though in the interim.
I'm testing the fix for this now.
Tested the fix and it solves this problem, but gdm doesn't start as we're getting some AVCs. allow xdm_t null_device_t:chr_file setattr; seems to be the significant one, and I don't see why /dev/null would need to be setattr'd as it's already root:root 0666 There's then an AVC of allow xdm_t self:capability sys_ptrace; but I think that's from gdb trying to attach as gdm crashes
Okay, updating to the latest selinux-policy seems to make things good. So we just need to tag that also and I think we should be good to go
It's tagged, closing this bug.