I only have su and sux installed, without sudo, gksu, and the likes.
The problems that may result from this potential bug may be seen here:
johndoe@siduction:~$ su -c env
Password: # enter root password
USER=root
HOME=/root
johndoe@siduction:~$ su-to-root -X -c 'env; sleep 10' # sleep 10s to catch output
# a new window opens from here on
About to execute env; sleep 10.
This command needs root privileges to be executed.
Using su...
Enter root password at prompt.
Password: # enter root password
USER=johndoe
HOME=/home/johndoe As can be seen from above, running su-to-root a graphical application that requires root privileges would run the app using the user's HOME dir, thereby making any changes to the application's settings be saved with root permissions.
This is tantamount to the behavior of sudo-ing graphical apps in Ubuntu, where the potential problems such behavior can cause range from non-persisting application settings to being denied of login because of messed up permissions of critical files inside HOME. [1]
This is the behavior I encountered when I ran GSmartControl from the XFCE menu,
$ cat /usr/share/applications/gsmartcontrol.desktop
# Run with root permissions.
Exec=su-to-root -X -c gsmartcontrol which created ~/.config/gsmartcontrol in my HOME dir with root permissions.
Consulting the manpages for su-to-root, the command is meant to be "an 'interactive' front-end to su" which "can be used in menu entry commands to ask for the root password." From the commands presented above, shouldn't it follow that "su -c env" and "su-to-root -X -c 'env; sleep 10'" at least share the same intended behavior of setting up the correct environment for running apps as root, and _not_ use the user's HOME dir?
Others who may be using gksu, kdesu, ktsuss, or any other front-ends may not be affected by this underiable su-to-root behavior.
[1] http://www.psychocats.net/ubuntu/graphicalsudo
EDIT:
The potential bug in su-to-root only happens when the su-like program that 'su-to-root -X' calls is sux (SU_TO_ROOT_X=sux, check the manpage for more info).
As said back in 2010 and present on the debian forums and irc
http://www.psychocats.net/ubuntu/graphicalsudo
That page may be accurate in regards to ubuntu but it is not accurate in regards to debian.
http://www.linfo.org/su.html
Quote from: piperThat page may be accurate in regards to ubuntu but it is not accurate in regards to debian.
I merely linked to that page to provide reference to details regarding the potential problems of running graphical root applications while using a user's HOME dir. The difference between sudo in Debian and sudo in Ubuntu is _very_ much clear to me, as I have explicitly stated in my post here (http://forum.siduction.org/index.php?topic=3077). :)
'su-to-root -X -c' any X11 apps that require root privileges, while having SU_TO_ROOT_X=sux, results in that application running as root _but_ using the user's HOME dir instead of root's HOME. This is the same behavior as sudo-ing X11 apps in Ubuntu, but _not_ in Debian.
If anyone wishes to replicate this potential bug, irrespective of the DE used, and see for themselves whether a bug or not, here are the
Steps to Reproduce:
1. Choose any X11 app, preferably one that requires root privileges, such as gsmartcontrol, and that resides inside /usr/bin, _not_ /usr/sbin.
2. Make sure that no previous configuration folder/files exist inside your HOME dir for the application you're about to run:
for GSmartControl: ~/.config/gsmartcontrol
Delete if exists.
3. Make sure sux is installed. Then run
# echo 'SU_TO_ROOT_X=sux' > /etc/su-to-rootrcThis will force using sux as the su-like program called by 'su-to-root -X' irrespective of whatever others are installed, such as gksu, kdesu, etc.
4. Run
$ su-to-root -X -c gsmartcontrol Make changes to the application settings. Then quit.
5. Verify that you now have the application's confugration files/folders but with root permissions inside your HOME dir.
If this isn't an undesired behavior then I don't know what is. I may have to file a bug soon on Debian BTS.
Cheers :)
Could you post the contents of
/etc/polkit-1/localauthority.conf.d/50-localauthority.conf
edit:deleted copy & paste for below post, not this one
$ cat /etc/polkit-1/localauthority.conf.d/50-localauthority.conf
# Configuration file for the PolicyKit Local Authority.
#
# DO NOT EDIT THIS FILE, it will be overwritten on update.
#
# See the pklocalauthority(8) man page for more information
# about configuring the Local Authority.
#
[Configuration]
AdminIdentities=unix-user:0
Running 'su-to-root -X -c /usr/sbin/synaptic' doesn't result in the unexpected behavior it seems. So there might still be some quirks with this odd behavior that I am seeing.
But, if you run 'su-to-root -X -c /usr/bin/gsmartcontrol', then you can expect the undesired behavior as stated previously.
Never tried out to see if the same is the case as with Synaptic, but thank you for pointing it out. :)
Will have to update my post.
QuoteVerify that you now have the application's confugration files/folders but with root permissions inside your HOME dir.
I cannot reproduce this on 4 machines
when I run
su-to-root -X -c /usr/sbin/synaptic.synaptic is under /root and not home
curious if you ever ran sudo on that machine
It may be early yet to say, but it seems that applications from /usr/bin are affected by the undesired behavior, but not those from /usr/sbin.
Quote from: "piper"curious if you ever ran sudo on that machine
stupid question that i see you have, interesting
/usr/bin
This directory contains the vast majority of binaries on your system. Executables in this directory vary widely. For instance vi, gcc, gnome-session and mozilla and are all found here.
/usr/sbin
This directory contains programs for administering a system, meant to be run by 'root'. Like '/sbin', it's not part of a user's $PATH. Examples of included binaries here are chroot, useradd, in.tftpd and pppconfig
It is an interesting discovery that applications from /usr/bin that wish to run with root privileges are the ones exhibiting the behavior.
/usr/bin/env being one other observation, it may be safe to say that the bug manifests in binaries located inside /usr/bin, wouldn't you agree?
what doesenv | grep PATHsay as user and root
$ env |grep PATH
GLADE_PIXMAP_PATH=:/usr/lib/glade3/modules
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
GLADE_MODULE_PATH=:/usr/share/glade3/pixmaps
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GLADE_CATALOG_PATH=:/usr/share/glade3/catalogs
# env |grep PATH
GLADE_PIXMAP_PATH=:/usr/lib/glade3/modules
GLADE_MODULE_PATH=:/usr/share/glade3/pixmaps
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
GLADE_CATALOG_PATH=:/usr/share/glade3/catalogs
piper@x1:~$ env |grep PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
WINDOWPATH=7
QT_PLUGIN_PATH=/home/piper/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/root@x1:/home/piper# env |grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
WINDOWPATH=7
QT_PLUGIN_PATH=/home/piper/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
not much help at all
hmm, your quote above
Quote$ cat /usr/share/applications/gsmartcontrol.desktop
# Run with root permissions.
Exec=su-to-root -X -c gsmartcontrol
have you tried that in kde
Quote from: "piper"have you tried that in kde
I can't. I don't have KDE in my system, only Xfce.
But like I said before, if my understanding is correct, the bug maybe triggered irrespective of the desktop environment that is used, so long as it is Debian and that the su-like program that 'su-to-root -X' calls is sux.
If you can try this
$ su-to-root -X -c '/usr/bin/env; sleep 10' in your KDE, then please pay close attention to the HOME variable. If it says anything but HOME=/root, then there's the problem.
I have already filed a bugreport on this here (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695882).
EDIT: corrected PATH -> HOME
piper@x1:~$ su-to-root -X -c '/usr/bin/env; sleep 10'
kdesu(16080)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ ../../kdesu/process.cpp : 293 ] Running "/bin/su"
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line "Password: "
kdesu(16080)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ ../../kdesu/process.cpp : 293 ] Running "/bin/su"
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line "Password: "
kdesu(16080)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave: [ ../../kdesu/process.cpp : 379 ] Child pid 16129
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line ""
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line "kdesu_stub"
kdesu(16080)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ ../../kdesu/process.cpp : 293 ] Running "/bin/su"
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line "Password: "
kdesu(16080)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave: [ ../../kdesu/process.cpp : 379 ] Child pid 16132
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line ""
kdesu(16080)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ ../../kdesu/su.cpp : 259 ] Read line "kdesu_stub"
piper@x1:~$
What is the output of $ cat /etc/su-to-rootrc on your system?
It seems you didn't properly read my post :). By your terminal output, The su-like program that 'su-to-root -X' calls is kdesu and _not_ sux, where the bug manifests.
It is _important_ that you # echo 'SU_TO_ROOT_X=sux' > /etc/su-to-rootrc before you run the $ su-to-rootrc -X -c '/usr/bin/env; sleep 10' Of course it goes without saying that you should verify that you have sux installed before trying to replicate the bug # apt-get install sux
To give further clarification this bug most probably will be of concern to those who use Xfce or LXDE, or other lightweight DE/WM. GNOME uses gksu while KDE uses kdesu. Gksu on the otherhand may be used by Gtk-based environments. Sux is for the minimalistic and terminal-inclined :).
By having _only_ sux installed, without the presence of its alternatives like gksu, kdesu, ktsuss, etc., 'su-to-root -X' will use sux, and you will know this when you're presented with a terminal asking for root password before running an app from the menu that requires root privilege.
Moreover, the bug seems to only manifest to applications that are run from /usr/bin, such as GSmartControl (/usr/bin/gsmartcontrol). Applications that run from /usr/sbin, such as Synaptic (/usr/sbin/synaptic) are not affected.
I build my own customized version of siduction with pyfll, sux is already installed and is by default for siduction located at /pyfll/packages/packages.d/pyfll-x-debian
To use sux at terminial type sux instead of su, give password
sux is just a wrapper to su to transfer your X credentials to the target user
example
sux
password
dbus-launch systemsettings
or
sux -l systemsettings
or
sux -l synaptic
by the way
piper@x1:~$ cat /etc/su-to-rootrc
SU_TO_ROOT_X=sux
piper@x1:~$
and please look at your bug report
QuoteOK, 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.
Probably this is not the expected behaviour, though it is pointless to
set SU_TO_ROOT_SU to su since it is the default value anyway.
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.
su-to-root -X -c systemsettings