This topic contains 10 replies, has 3 voices, and was last updated by skidoo Apr 28-12:11 am.
April 19, 2019 at 12:37 pm #20567Member
AFAICT, nothing currently passes -r or –root when calling desktop-defaults-run
the latter case is contrary to “lean and mean” ~~ it unnecessarily causes an intermediary gksu process to run throughout the duration of each launched item. 3x, 5x, 8x instances of items launched into “default terminal” and/or “default editor” winds up consuming an extra 35-50Mb for naught.
#IFS="|" if [ -z "$args" ]; then xtraargs=""; fi if [ "$exec_root" = 1 ]; then gksu -u root "$Exec $xtraargs $args" 2>/dev/null & exit else echo "$Exec $xtraargs $args" gksu -u $(whoami) "$Exec $xtraargs $args" 2>/dev/null & exit fi
Is there _ever_ a valid reason, a valid use case for invoking
gksu -u demo desktop-defaults-run -b
( if there is, apparently I’m blind to it )
“-u myself” will not be supported in the forthcoming gksu version.
and “-u root” will similarly fail ~~ implicitly, invariably, ALL calls to gksu (and/or gksudo)
will invoke sudo to launch a requested program with elevated privileges.
(restated, for clarity: the -u option is deprecated)
Please test and confirm ~~ even under the current version of gksu, “-u root” is superfluous
-u root“$Exec $xtraargs $args” 2>/dev/null &
^— If the result is equally effective, is identical, with or without explicitly passing the “-u root” option
the “-u root” can be removed (now, already) from existing commandstrings which invoke gksu.April 19, 2019 at 5:52 pm #20576Forum Admin
only thing I can think of would be if some root app was calling a web browswer and then needed to start as an unprivledged user.April 19, 2019 at 7:20 pm #20580Forum Admin
Hmm it has been a while but iirc the “session variables” were missing when the script directly called the app. So stuff like no gtk/qt theme was set, the X environment info was missing so the app would error out and not start (geany specifically had this a lot iirc), permissions were incorrect when the called apps were handling user configs.
If it works fine now there is no need for it anymore. At the time there were bugs that I cannot recall at the moment. However even calling apps from a (root) terminal would also error out, have the wrong theme set, have incorrect / set incorrect permissions, etc. I did read on the mx forums about this being fixed?!?
Computers are like air conditioners. They work fine until you start opening Windows. ~Author UnknownApril 19, 2019 at 8:48 pm #20582Member
The sudoers file specifies (or can) which environment variables shall be preserved. Currently, no theme-related envvar is preserved & that seems ideal ~~ it causes (or enables) the windows of apps with elevated permissions to have distinctively different theming.
I did read on the mx forums about this being fixed?!?
idunno the timeframe of what you’re referring to. Fixed, as in corrected
or (more recently, discussing the pending new version) fixed, as in, invariable.
In the pending version, the following (bolded) is invariable
sudo -H -S -u root –– leafpad
with extremely limited options
$ gksu -h gksu version 2.1.1 Usage: gksu [options] <command> ============= NOTICE ============== As of version 2.1.1, gksu and gksudo identically provide a graphical frontend to __sudo__. -=- Their purpose is to enable you to run graphical commands that require elevated permissions, (without the need to run sudo directly, via an X terminal emulator). =================================== --debug, -d Print information to the (terminal) screen which might be useful for diagnosing and/or solving problems. --preserve-env, -k Preserve the current environment variables (refer to gksu manpage for details --login, -l Make this a login shell (refer to gksu manpage for details)
excerpt from the WIP gksu manpage:
IN ORDER TO ENSURE ‘INFORMED CONSENT’, DURING EVERY INVOCATION
>>>>> IRRESPECTIVE OF ANY CONFIGURED SUDO(ers) TIMEOUT <<<<<
gksu (or its alias, gksudo) PRESENTS A POPUP
DISPLAYING THE TO-BE-AUTHORIZED COMMANDSTRING AND REQUESTING PASSWORD ENTRY.
Preserve the current environment variables.
NOTE: the exact set of preserved variables is configured by editing the sudoers file using the visudo tool. (On antiX systems, keep_env+= declarations can be stated within /etc/sudoers.d/antixers also.)
apropos sudo and consult the relevant manpages to learn about sudo configuration details.
Make this a login shell, aka launch the <command> within a login shell wrapper. Beware ~~ doing so may cause problems with the Xauthority magic (‘magic-cookie’ auth tokens). Casual use of this option is discouraged; it is provided for use by advanced users, to accommodate esoteric usage scenarios. Esoteric ~= not commonly considered during day-to-day activities. Example: On a Debian-derived or Ubuntu-derived operating system, the default login shell might be dash (or sh) instead of bash. Cumulatively, each shell process adds session overhead… and someone who intends to launch many (many!) long-running shelled processes might choose to invoke lighter-weight sh shells for each of those processes.
If invoked by an already su//sudo//root elevated-permissioned process, gksu will (must) refuse to run. In that context, sudo would immediately accept and run any commandstring passed to it via gksu, without providing an opportunity for the user to inspect the slated commandstring.
For the version of gksu installed on this system, when gksu passes a request to sudo, “root” is the hardcoded RunAs target user. To use gksu on a system where the root account has been disabled, you can setup sudoers aliasing.
(For details, refer to the sudoers(1) manpage; keywords: Runas_Member, Runas_Spec, Runas_List)April 19, 2019 at 9:34 pm #20583Forum Admin
Fixed as in corrected. It was a number of years ago so I am a little unclear about it now. Running the command directly had troubles, same with running su to call the program, I cannot recall if sudo worked or not… I think it had similar issues as well as needing to find a way to prompt for a password. Gksu was there, it worked without the problems that came when calling the program directly, and was already being used in the same / similar way in the control centre at the time. (which is mainly what desktop-defaults-run was for… to make it easier to switch terminals/editors/file manager without breaking the control centre, menu, and toolbar).
Here is the thread I was thinking about from the mx forums.
I do hope it is not necessary anymore.
- This reply was modified 6 months ago by Dave.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author UnknownApril 19, 2019 at 11:21 pm #20589Member
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:
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.
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:
In the absence of these, su-to-root will default to using gksu for SU_TO_ROOT_X
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)April 19, 2019 at 11:49 pm #20590Member
$ sudo grep -inr ‘su-to-root’
bin/antixcc.sh:451: “desktop-defaults-run -t su-to-root -c ‘/usr/local/bin/ddm-mx -i nvidia’ &” \
bin/antixcc.sh:493: “su-to-root -X -c codecs &” \
bin/antixcc.sh:499: “su-to-root -X -c broadcom-manager &” \
bin/antixcc.sh:505: “su-to-root -X -c repo-manager &” \
$sudo grep -inr ‘su-to-root’
$ sudo grep -inr ‘su-to-root’
gsmartcontrol-root:5:su-to-root -X -c ‘gsmartcontrol $@’
Binary file spacefm matches
su-to-root:3:if test -r /etc/su-to-rootrc; then
su-to-root:7:if test -r ~/.su-to-rootrc; then
su-to-root:21: txt=”$(gettext su-to-root “$txt”)”;
su-to-root:113: x-terminal-emulator -e su-to-root -p “$PRIV” -c “$COMMAND”;;
su-to-root:116: *) x-terminal-emulator -e su-to-root -p “$PRIV” -c “$COMMAND”;;
umts-panel:86: if os.access(‘/usr/bin/su-to-root’,os.R_OK):
umts-panel:87: os.system(‘su-to-root -X -c “/usr/bin/umts-panel-configure ‘+home+'” &’)
$ sudo grep -inr ‘su-to-root’
$ sudo grep -inr ‘su-to-root’
dkms:3010: for getroot in su-to-root gksudo kdesu sudo; do
pppoeconf:41: elif which su-to-root >/dev/null; then
pppoeconf:42: exec su-to-root $X11 -c “$0” “$@” || exit 1April 20, 2019 at 9:31 am #20592Member
sudo tail -38 /usr/bin/su-to-root
Dave, back-in-the-day, maybe the issue was with sux (not gksu) calling x-terminal-emulator and expecting a username option to be passed? As shown in the previous post, across all the callers to su-to-root (as found in antiX 17.4 full), none expects or needs or pass that option.April 26, 2019 at 12:51 pm #20734Member
page is marked public, but can’t view the code & no link provided to “fork” it
(so that I can then remove the -u $(whoami) from desktop-defaults-run and send a pull request)
Instead of wrestling with dpkg-divert to handle a replaced copy of /usr/bin/su-to-root, I’ll just set gksu to disregard -u
April 27, 2019 at 10:28 pm #20804Forum Admin
- This reply was modified 5 months, 4 weeks ago by skidoo.
Sorry skidoo, missed your messages as the thread showed as read and I never received a message of a new post…
Back in the day is exactly that and I cannot recall the exact issues. Only I know that what is in there was about the only thing that worked (for me) at the time. I do recall a bit of a mess in the whole area with almost everything being used in some way… sux yes was there as well as ktsuss and something else.
Looked at gitlab, I am not certain how to open it up to the world for cloning…. I found an option that does allow this, however it also allows pushing to the repository by anyone. The way I see it while using gitlab it is required to make a group, add the group to all the projects, and then add yourself and anyone else to the group. Seems kind of silly to me though.
By replaced copy of su-to-root I am guessing that you seen the lines that basically translate every -X call to a gksu -u (or similar) call?
Rather than simply removing the -u call from desktop-defaults-run I should just change to su-to-root -X -c ?
Computers are like air conditioners. They work fine until you start opening Windows. ~Author UnknownApril 28, 2019 at 12:11 am #20805Member
posted “nevermind” b/c even if you would alter calls to su-to-root within desktop-defaults-run,
su-to-root (provided by “menu” package) still has a hardcoded -u when invoking gksu, (would necessitate a dpkg diversion to override/overwrite it)
AFAICT, everything seen in antiX calls, or implicitly expects, “-u root” when calling gksu.
As seen in desktop-defaults-run:
gksu -u $(whoami)
Under both the old, and updated, version of gksu
(as “gksu -d blahbla” will show)
is the fixed, unconditional, behavior ~~ home directory of the user is preserved, so the -u is rather pointless (we have no “wheel” or other admin -empowered user, and all login accounts have equal grants in sudoers, so no reason to ever want/need to RunAs any user other than “root”)
Until my recent post, I had intended to flesh out any edge cases by aborting if -u option is passed to gksu. Now the plan is to simply ignore/disregard -u if it that option is passed (and continue, same as ever, passing “sudo -H -u root blahbla” to the sudo backend.
You must be logged in to reply to this topic.