> From: Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> > To: Ian Pangilinan <snailbox88-...@yahoo.com>; 695...@bugs.debian.org > Cc: > Sent: Friday, December 14, 2012 8:48 PM > Subject: Re: Bug#695882: menu: su-to-root runs root applications using user's > HOME, when SU_TO_ROOT_X=sux > > As you can see, su-to-root is a rather stupid wrapper and does not make
> any policy decision by itself. Whether HOME should be kept or changed is a > policy decision, and the su-to-root documentation does not take side on this > issue. The manpage for su-to-root didn't mention about this, so the problem must be with sux, but only when it is called from su-to-root? I remember there's still that other problem with sux in Debian concerning having 'no job control in this shell.' > For me it fails with > 'env: -c: No such file or directory' I get that same message when I set SU_TO_ROOT_SU=sux in /etc/su-to-rootrc. I guess I didn't explicitly differentiate between SU_TO_ROOT_X and SU_TO_ROOT_SU in my forum posts. I recommended setting SU_TO_ROOT_X=sux in /etc/su-to-rootrc so that invoking 'su-to-root -X' does not try to use gksu, kdesu, etc. if they are present, as the bug manifests when sux is used, i.e. running an application from the menu, which requires root privilege, opens up a terminal window to enter the root password. With regard to SU_TO_ROOT_SU, as per the manpage the default is SU_TO_ROOT_SU=su. To help you replicate the behavior I was observing, please see if /etc/su-to-rootrc in your system contains the following: SU_TO_ROOT_X=sux SU_TO_ROOT_SU=su > So what su-to-root script do you use ? I'm not really using any script. I observed the undesired behavior when I ran GSmartControl by selecting it from the menu. Upon inspecting the .desktop for GSmartControl, it has Exec=su-to-root -X -c gsmartcontrol for invoking the application. $(which gsmartcontrol) returns /usr/bin/gsmartcontrol. $(which env) returns /usr/bin/env. Both are affected by the bug of running them as root but having HOME directory as the user's. (su-to-root -X -c gsmartcontrol / su-to-root -X -c env) $(which synaptic) returns /usr/sbin/synaptic, but the application is not affected by the bug. The application's settings are saved in root's HOME directory. (su-to-root -X -c synaptic) From these observations we can narrow down further the bug as manifesting on binaries originating from /usr/bin/, but not from /usr/sbin/. I hope these will help in troubleshooting the problem. I have also indicated Steps to Reproduce from the previous forum links. Cheers, ianp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
