Bug 661072

Summary: su does not permit X applications to display
Product: [Fedora] Fedora Reporter: Tom "spot" Callaway <tcallawa>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: alexandre.magaz, aquini, brendan.jones.it, honeybeenet, kdudka, ovasik, p, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-16 13:31:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
sample code to illustrate issue none

Description Tom "spot" Callaway 2010-12-07 13:53:00 EST
Created attachment 467128 [details]
sample code to illustrate issue

I have attached a .c file which is intended to be part of a gedit plugin, but functions as a standalone binary.

When compiled, and executed via su on Fedora 13 (x86_64, although, I doubt arch matters), this is the result:

[spot@f13 ~]$ touch /tmp/foo
[spot@f13 ~]$ su - --command="/home/spot/gedit-beesu-plugin gedit-beesu-plugin /usr/bin/gedit gedit /tmp/foo"
Password:
Entering main.
Checking for the lockfile /tmp/foo...
...found it!
About to unlink the lockfile.
About to spawn the daemon().
Filling Commandline
About to execvp(/usr/bin/gedit, gedit (null))

*** gedit opens, as root, in the X session (GNOME) ***

Now, when I try to do the same thing on Fedora 14 (x86_64), it fails:
[spot@pterodactyl ~]$ su - --command="/home/spot/gedit-beesu-plugin gedit-beesu-plugin /usr/bin/gedit gedit /tmp/foo"
Password: 
Entering main.
Checking for the lockfile /tmp/foo...
...found it!
About to unlink the lockfile.
About to spawn the daemon().
Filling Commandline
About to execvp(/usr/bin/gedit, gedit (null))
[spot@pterodactyl ~]$ No protocol specified

(gedit:1808): Gtk-WARNING **: cannot open display: :0.0

******
Now, the env values from both systems show that XAUTHORITY and DISPLAY are surviving through su. There is no change if -p is passed to su (it works on F13, it does not work on F14).

sudo works properly on both systems, where my user is in sudoers with ALL=(ALL)	ALL (invocation: sudo -- /home/spot/gedit-beesu-plugin gedit-beesu-plugin /usr/bin/gedit gedit /tmp/foo), which leads me to believe the bug is in su.
Comment 1 Pádraig Brady 2010-12-08 05:55:42 EST
I suspected $HOME was being messed with, but
that doesn't seem to be the case on testing (and you tried with -p).
Perhaps it's a pam_xauth issue as that's a difference on my F14 system
(which has no issue running gedit under su)

$ sudo su -c "env | grep -E '^(XA|HOME)'"
HOME=/root
XAUTHORITY=/root/.xauthreIlSs
$ sudo env | grep -E '^(XA|HOME)'
XAUTHORITY=/var/run/gdm/auth-for-padraig-minIH1/database
HOME=/root

man pam_xauth has details on that.
Comment 2 bee 2010-12-08 07:01:19 EST
Hi!!!!!!!!!!!!
I don't have much to say nor add!!!!!!! Only two things maybe!!!!!!!
But at first THANKS to TOM!!!!!!!!!!!!!!!!!!!!

1)
Well, i could confirm it's not related to the architecture because i've a x86_32 (32bit) PC!!!!!! and the 32bit F13 works, but the 32bit F14 doesn't work!!!!

2)
I managed to find these results, so also i think that the environment variables of SU are correct in both F13 and F14!!!!!!!! then, i very don't know where is the error!!!!!

------- F13 32bit
$ su -
# env | grep -v LS_COLORS
HOSTNAME=localhost.localdomain
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
QTDIR=/usr/lib/qt-3.3
QTINC=/usr/lib/qt-3.3/include
USER=root
MAIL=/var/spool/mail/root
PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
PWD=/root
LANG=en_US.UTF-8
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LOGNAME=root
QTLIB=/usr/lib/qt-3.3/lib
CVS_RSH=ssh
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=:0.0
G_BROKEN_FILENAMES=1
XAUTHORITY=/root/.xauthoy5Fmi
_=/bin/env

------- F14 32bit
$ su -
# env | grep -v LS_COLORS
HOSTNAME=localhost.localdomain
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
USER=root
MAIL=/var/spool/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
PWD=/root
LANG=en_US.UTF-8
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LOGNAME=root
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=:0.0
G_BROKEN_FILENAMES=1
XAUTHORITY=/root/.xauthuwte3V
_=/bin/env

----------------------------------------

The outputs are the same!!!!!!!!!!!!!!!!!!! There is only some minor differences mostly related to the QT!!!!! and to different names for the random-generated temporary files!!!!!
The "XAUTHORITY" (i don't know what is that about!!!) and "DISPLAY" variables persist in F13 but also in F14!!!!!
The internet says the functions "daemon" (it's like a magic "fork"!!!) and "execvp" preserve environment variables!!!!!
Well, i can only say that, and confirm TOM's very right!!!!!!!!

But i'm thinking about this!!!!!!!!! If both: SU and the C functions, preserve the environment variables, maybe the problem isn't related to the environment variables!?!!!!!!!! Could this be possible!!!!!?! Maybe the error messages are wrong (they're errors themselves!!!!) or they're only a consequence of other 'hidden' errors that happens before!!!!!

bye!!!!!!!!!!!
~bee!!!!!!
Comment 3 Ondrej Vasik 2010-12-08 07:42:51 EST
Just as sidenote. These "qt related" things might mean that profile.d scripts are not processed in F-14 run (as these envvars are set by profile.d scripts). I don't think the issue is directly in su - there were no changes in su between 8.4 (f13) and 8.5(f14) ... and all the changes from f14 are backported to f13...
So probably something in PAM or setup(/etc/profile,/etc/bashrc) ...
Comment 4 Brendan Jones 2010-12-08 08:19:40 EST
I haven't looked to deeply into your issue but similar bugs have been noted here in case that helps: http://fedoraproject.org/wiki/Common_F14_bugs#Cannot_launch_various_graphical_applications_.28gedit.2C_nautilus....29_as_root_from_a_console




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Tom "spot" Callaway 2010-12-08 15:05:24 EST
Please note, this isn't "run gedit under su", which works fine on F14 (at least for me), it is specific to the case and situation I have posted.
Comment 6 Tom "spot" Callaway 2010-12-13 16:27:28 EST
(In reply to comment #1)
> I suspected $HOME was being messed with, but
> that doesn't seem to be the case on testing (and you tried with -p).
> Perhaps it's a pam_xauth issue as that's a difference on my F14 system
> (which has no issue running gedit under su)
> 
> $ sudo su -c "env | grep -E '^(XA|HOME)'"
> HOME=/root
> XAUTHORITY=/root/.xauthreIlSs
> $ sudo env | grep -E '^(XA|HOME)'
> XAUTHORITY=/var/run/gdm/auth-for-padraig-minIH1/database
> HOME=/root
> 
> man pam_xauth has details on that.

pam_xauth should be identical between F13 and F14, so I don't think that's it.
Comment 7 Tom "spot" Callaway 2010-12-16 13:31:42 EST
I figured this out with help from Nalin Dahyabhai:

The sample code does this:


                 if(daemon(1,1) == 0)
                    {
                        if(argc > (REQUIRED_ARGC + 1))
                            commandline[1] = argv[REQUIRED_ARGC + 1]; 
                        execvp(command, commandline);
                    }

Nalin noted that when daemon() is called, it forks off into a child process, which causes a race condition between su cleaning up the XAUTHORITY cookie and the child launching. Neither of us are sure why this triggers 100% of the time on F-14 vs never on F-13, perhaps a change in how F-14 does scheduling, but Nalin suggests that using daemon() at all in this situation is incorrect.

I tested the code with the daemon() invocation removed and it works as expected. My best guess is that the daemon() was intended to keep the original gedit alive while the "run as root" gedit child is active, otherwise, the first gedit waits for the child to finish.

Either way, this is not really a bug in su (or pam_xauth), so I'm closing this bug out.
Comment 8 bee 2010-12-16 17:12:19 EST
Hi TOM!!!!!!!!!

> daemon()
> it forks off into a child process,
> which causes a race condition between su cleaning up the XAUTHORITY cookie and
> the child launching.

I ain't sure about that!!!!!!!!!!!
I think "daemon()" is a function made on purpose to start a new "daemon" (a new "task"!! actually a fork!) without dependencies on its parent(s)!!!!!!
SU doesn't damage anything!!!!!!! In the email i sent you, there is the code you can type in a terminal to test what i am saying!!!!!!!!!!
Even if "su" terminates, all running tasks will continue to work like before!!!! (this works even in F14!!!!!!!!)
I used this magic daemon() function, because it works very well everywhere!!!!!!!
Yeah Fedora 14, aside!!!!!!!!!!!

bye!!!!!!!!!!!!
~bee!!!!!!