Bug 661072

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.

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!!!!!!

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) ...

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

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.

(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.

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.

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!!!!!!