On Sun, 16 Dec 2012 12:48:22 +0100, bill.allomb...@math.u-bordeaux1.fr wrote: > > And after the fix, what does it do ?
It does what it should, running root application stores configuration inside root's $HOME instead of the user's. > This suggest that software in /usr/sbin are aware of the $HOME problem and do > the right thing, but not gsmartcontrol. Hmm, you have a point, but I have no prior idea about /usr/sbin software doing the right thing about the $HOME problem, nor any vague notion on how this mechanism is taking place. > By the way, if gsmartcontrol need to run as root, why is it not in /usr/sbin ? This is a question more suited for gsmartcontrol's maintainer I believe. :-) What I can only tell you is that the gsmartcontrol.desktop file that launches it has 'Exec=su-to-root -X -c gsmartcontrol' for the command. Maybe this is a non-issue if alternatives such as gksu or kdesu are called instead of su/sux, but as it is, I happened to come upon a condition where the combination of su-to-root and su/sux triggered an unexpected behavior in gsmartcontrol. > This is not a security implication, but rather that it is likely to recreate > the > > problems in bugs #246886 and #150314 on some systems. If it is the design of /usr/sbin software doing some kind of action of being aware of the $HOME problem, then the bug is looking more like one of GSmartControl than that of su-to-root. ianp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
