Anonymous
Dave, thanks for linking that MX topic. gksu should be unaffected by the sudo-related problems described there, except for its interaction with the “su-to-root” command (a bash script, provided by the debian “menu” package)
From the su-to-root manpage:
ENVIRONMENT
SU_TO_ROOT_X
Select the su-like program called by su-to-root -X. Supported values are gksu, kdesu, kde4su, ktsuss, sux, gksudo and kdesudo. kde4su denotes the KDE4 version of kdesu.When this variable is not set su-to-root will currently try to use gksu, kdesu, kde4su, ktsuss, sux and the built-in code, in that order with the exception that under a KDE session, kdesu and kde4su are prefered over gksu.
FILES
/etc/su-to-rootrc
~/.su-to-rootrc
su-to-root will source these files at startup in this order. This lets you define and modify the environment variables above without restarting your X session.
$ set | grep ‘ROOT’
AFAICT, antiX does not populate either of these envvars:
SU_TO_ROOT_X
SU_TO_ROOT_SU
In the absence of these, su-to-root will default to using gksu for SU_TO_ROOT_X
/usr/bin/su-to-root
case $SU_TO_ROOT_X in
gksu) gksu -u “$PRIV” “$COMMAND”;;
With the generous (lax) sudoers directives as a given…
# User privilege specification
root ALL=(ALL:ALL) ALL# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
…x-terminal-emulator -e “sudo -H -S -u root –– <command>”
remains available as an alternative (an alternative to undermining gksu security in a multiseat context)