Potential bug? su-to-root using user's HOME instead of root

[braveheartleo]

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:

Code Select Expand

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,

Code Select Expand

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

[piper]

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

[braveheartleo]

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

'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

Code Select Expand

# 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

Code Select Expand

$ 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

[piper]

Could you post the contents of

Code Select Expand

/etc/polkit-1/localauthority.conf.d/50-localauthority.conf

edit:deleted copy & paste for below post, not this one

[braveheartleo]

Code Select Expand

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

[piper]

Verify 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

Code Select Expand

su-to-root -X -c /usr/sbin/synaptic

.synaptic is under /root and not home

[piper]

curious if you ever ran sudo on that machine

[braveheartleo]

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.

[piper]

curious if you ever ran sudo on that machine

stupid question that i see you have, interesting

[piper]

/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

[braveheartleo]

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?

[piper]

what does

Code Select Expand

env | grep PATHsay as user and root

[braveheartleo]

Code Select Expand

$ 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]

Code Select Expand

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/

Code Select Expand

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

$ cat /usr/share/applications/gsmartcontrol.desktop
# Run with root permissions.
Exec=su-to-root -X -c gsmartcontrol

have you tried that in kde

[braveheartleo]

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

Code Select Expand

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

EDIT: corrected PATH -> HOME