(/usr/local/bin/) desktop-defaults-run

Forum Forums antiX-development Development (/usr/local/bin/) desktop-defaults-run

This topic contains 10 replies, has 3 voices, and was last updated by skidoo Apr 28-12:11 am.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #20567
    Member
    Avatar
    skidoo

    AFAICT, nothing currently passes -r or –root when calling desktop-defaults-run
    and
    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
    gksu -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.

    #20576
    Forum Admin
    dolphin_oracle
    dolphin_oracle

    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.

    #20580
    Forum Admin
    Dave
    Dave

    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 Unknown

    #20582
    Member
    Avatar
    skidoo

    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

    gksu leafpad
    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:

    {snip}

    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.

    {snip}

    –preserve-env, -k
    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.

    –login, -l
    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.

    {snip}

    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)

    #20583
    Forum Admin
    Dave
    Dave

    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.
    https://forum.mxlinux.org/viewtopic.php?p=496905#p496905

    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 Unknown

    #20589
    Member
    Avatar
    skidoo

    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)

    #20590
    Member
    Avatar
    skidoo

    /usr/local
    $ 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 &” \
    demo@antix1:/usr/local

    /bin
    $sudo grep -inr ‘su-to-root’

    /usr/bin
    $ 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:4:. /etc/su-to-rootrc
    su-to-root:7:if test -r ~/.su-to-rootrc; then
    su-to-root:8:. ~/.su-to-rootrc
    su-to-root:21: txt=”$(gettext su-to-root “$txt”)”;
    su-to-root:102: SU_TO_ROOT_X=su-to-root
    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+'” &’)

    /sbin
    $ sudo grep -inr ‘su-to-root’

    /usr/sbin
    $ sudo grep -inr ‘su-to-root’
    dkms:3010: for getroot in su-to-root gksudo kdesu sudo; do
    dkms:3013: su-to-root)
    pppoeconf:41: elif which su-to-root >/dev/null; then
    pppoeconf:42: exec su-to-root $X11 -c “$0” “$@” || exit 1

    #20592
    Member
    Avatar
    skidoo

    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.

    #20734
    Member
    Avatar
    skidoo

    https://gitlab.com/antiX-Linux/desktop-session-antix

    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)

    edit:
    nevermind ~~
    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

    • This reply was modified 5 months, 4 weeks ago by skidoo.
    #20804
    Forum Admin
    Dave
    Dave

    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 Unknown

    #20805
    Member
    Avatar
    skidoo

    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)
    sudo -H
    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.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.