Bug 442061 - graphical apps unable to start as root in user session
graphical apps unable to start as root in user session
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
: Reopened
: 441831 442157 442168 456516 (view as bug list)
Depends On:
Blocks: F9PR F10Alpha/F10AlphaBlocker
  Show dependency treegraph
 
Reported: 2008-04-11 11:00 EDT by Jeremy Katz
Modified: 2015-01-14 18:20 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-01 11:55:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2008-04-11 11:00:18 EDT
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.
Comment 1 Jeremy Katz 2008-04-11 11:01:56 EDT
And running 'xhost +' works around, but seems like the wrong answer :)
Comment 2 Jeremy Katz 2008-04-11 13:33:15 EDT
This is because we can't create the lock in /var/run/gdm where the xauth cookie
is living.
Comment 3 Ray Strode [halfline] 2008-04-11 15:13:21 EDT
*** Bug 441831 has been marked as a duplicate of this bug. ***
Comment 4 Jeffrey C. Ollie 2008-04-11 15:16:37 EDT
This also affects SSH'ing to other hosts since the X forwarding code in SSH
needs to access the xauth cookies.
Comment 5 Jeffrey C. Ollie 2008-04-11 15:38:12 EDT
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.
Comment 6 Tom London 2008-04-11 16:26:58 EDT
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.....]
Comment 7 Jeffrey C. Ollie 2008-04-11 16:34:11 EDT
Yeah, the same was reported on IRC, try:

http://koji.fedoraproject.org/koji/buildinfo?buildID=45962

Once it's done building.
Comment 8 Tom London 2008-04-11 16:45:39 EDT
Yeah..... that works.
Comment 9 Ray Strode [halfline] 2008-04-11 16:59:50 EDT
good!
Comment 10 Michal Schmidt 2008-04-12 17:26:24 EDT
*** Bug 442157 has been marked as a duplicate of this bug. ***
Comment 11 Ondrej Vasik 2008-04-14 05:03:25 EDT
*** Bug 442168 has been marked as a duplicate of this bug. ***
Comment 12 Jeremy Katz 2008-07-24 14:46:13 EDT
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
Comment 13 Bill Nottingham 2008-07-25 10:36:11 EDT
*** Bug 456516 has been marked as a duplicate of this bug. ***
Comment 14 Matthias Clasen 2008-07-25 19:36:34 EDT
Yeah, we need a better fix here, either fix the stupid locking in libXau or
create per-user subdirectories in /var/run/gdm
Comment 15 Jeremy Katz 2008-07-28 14:47:27 EDT
Note that some resolution of this is required for Fedora 10 alpha, as otherwise,
installs from live images are non-functional.  
Comment 16 Ray Strode [halfline] 2008-07-28 14:56:33 EDT
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.
Comment 17 jmccann 2008-07-28 15:10:46 EDT
I'm testing the fix for this now.
Comment 18 Jeremy Katz 2008-07-31 12:45:16 EDT
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
Comment 19 Jeremy Katz 2008-07-31 13:52:36 EDT
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
Comment 20 Jesse Keating 2008-08-01 11:55:06 EDT
It's tagged, closing this bug.

Note You need to log in before you can comment on or make changes to this bug.