On Fri, 14 Dec 2012 16:43:18 +0100, bill.allomb...@math.u-bordeaux1.fr wrote: > > Are you using systemd ?
Nope, I'm using the good ol' sys-v init. > I get this error when calling > DISPLAY=:0 SU_TO_ROOT_X=sux su-to-root -X -c xterm > > and su-to-root -X will set SU_TO_ROOT_SU to sux by itself. I see that I should have DISPLAY=:0 along with the command SU_TO_ROOT_X=sux su- to-root -X -c. I always wondered why the terminal window that opens always indicate 'Using su...' instead of 'Using sux...' This is what I have observed prior to creating /etc/su-to-rootrc: ianp@sid:~$ SU_TO_ROOT_X=sux su-to-root -X -c xterm About to execute xterm. This command needs root privileges to be executed. Using su... Enter root password at prompt. Password: ianp@sid:~$ DISPLAY=:0 SU_TO_ROOT_X=sux su-to-root -X -c xterm About to execute xterm. This command needs root privileges to be executed. Using sux... Enter root password at prompt. Password: I paid little attention to the message, thinking that sux is a wrapper for su after all. So I have been running SU_TO_ROOT_X=sux su-to-root -X -c with su all this time. Learning as I move along. A quick question though: Why SU_TO_ROOT_X=gksu su-to-root -X -c runs with gksu, but SU_TO_ROOT_X=sux su-to-root -X -c runs with su instead of sux? I don't have /etc/su-to-rootrc. > OK, I see what you report: by setting SU_TO_ROOT_SU=su, > you force su-to-root to use su instead of sux, so you > are actually using su, so you are bypassing the bug with su-to-root. Indeed I have been running su-to-root with su all this time, as I have only come to know just now. And we have found the bug with su-to-root using sux, but unfortunately not the bug I'm reporting about. > Now to your report, it seems the su behaviour is correct, see the bug reports > #246886 and #150314. Basically, if su reset $HOME, then X programs will fail > to find the .Xauthority file. I have read through the bug reports you have indicated. These explain to me why su-to-root using su retains the user's $HOME. And this is where my bug report lies. Running root applications that is using the user's $HOME results in the creation of files/folders having root permissions. I encountered this undesired behavior with GSmartControl: ianp@sid:~$ cat /usr/share/applications/gsmartcontrol.desktop Exec=su-to-root -X -c gsmartcontrol Upon clicking on the GSmartControl menu entry, I am presented with a terminal window with the following messages: About to execute gsmartcontrol. This command needs root privileges to be executed. Using su... Enter root password at prompt. Password: This is prior to creating /etc/su-to-rootrc. > Please remove SU_TO_ROOT_SU=su from your su-to-rootrc file and try the script > in attachment which fix the bug with sux. I see that you made the following change to /usr/bin/su-to-root: - sux) suname=sux; pwuser="$PRIV"; cmd='sux -p "$PRIV" -c "$COMMAND"';; + sux) suname=sux; pwuser="$PRIV"; cmd='sux -p "$PRIV" "$COMMAND"';; And I can confirm that it fixes the bug with su-to-root using sux. Unfortunately and as expected, it is still the same undesired behavior as with su: root application is using user's $HOME. No /etc/su-to-rootrc. ianp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
