[sudo-users] security bug -- sudo undefines functions in environment

L. A. Walsh sudo at tlinx.org
Tue Aug 5 19:35:45 MDT 2014

Edgar wrote:
> PS1='\u@\h:\w\$ '
> You can also use PROMPT_COMMAND.
Too limted.

I have something like:
    read _CRST <<<"$(tput sgr0)"   #Reset
    read _CRed <<<"$(tput setaf 1)"  #Red
     read _CBLD <<<"$(tput bold)"   #Bold
    declare _prompt_open="" _prompt_close="" _prompt=">"
    declare _disp_port=${DISPLAY/[^:]*:/}
    printf -v qUSER "%q" $USER
    typeset -x qUSER

    [[ $UID -eq 0 ]] && {
    PS1='\['"$_prompt_open"'\]$(spwd "$PWD" 
)'"$_prompt"'\['"$_prompt_close"'\] ';
    if [[ -n ${REMOTEHOST:-""} ]]; then
        function titlebar { \
            printf "\033]1;${qUSER}@${HOSTNAME}:%q\007" "$(spwd "$PWD")" ;\
        export -f titlebar

"$PWD")'"$_prompt"'\['"$_prompt_close"'\] '

The swpd function is a bit complicated as it adjusted how much it shows
based on screen width and how long the prompt is:

if [[ ! ${qUSER:-""} ]]; then
     printf -v qUSER "%q" $USER
     export qUSER
export _home_prefix=${HOME%/*}/

#next func idea came from suse, but the code became a complete rewrite
# return a shorted path when displayed path would take up > 50% width of 

alias int=declare\ -i _e=echo _pf=printf exp=export ret=return
exp __dpf__='local -a PF=(
                                "..." )'
function spwd () {  \
    (($#)) || { _e "spwd called with null arg"; return 1; }; \
    int w=COLUMNS/2                                                    ;\
    ( _pf -v _p "%s" "$1" ; export IFS=/         ;\
         set $_p; shift; unset IFS                            ;\
        t="${_p#$_home_prefix}"                                ;\
        int tl=${#t}                                                     ;\
        if (($#<=6 && tl<w));then ((tl<=2)) && \
             { _e -En "${_p}";return 0; }                ;\
            eval "$__dpf__"                                            ;\
            int i pfl=${#PF[*]}                                 ;\
            for ((i=0; i<pfl; ++i)); do    eval         \
                 "_pf -v _pa %s \"${PF[i]}\""            ;\
                _p="$(eval "_pf %s \"$_pa\"")"        ;\
                ((${#_p}<w)) && break;     done            ;\
        _e -En "${_p#$_home_prefix}" )        

the PF are the various "short forms" of the prompt that
get tried based on space.

The PS1 prompt also sets my Terminal title w/current dir so I can
know what window is open to what dir when all are minimized.

>> a command line
>> is coming from/going to is of basic usefulness to me.  Having some
>> indication of my
>> location gives me context.
> Now I can be logged in remotely or not -- so knowing what computer
> True. Rebooting the wrong host....
> I wonder if it is possible at all to create a breadcrum trail.
Have rebooted wrong system.  Not fun, but not fatal... just a pain.

>  I might have 6-8 console windows open at
>> once (some may be
>> minimized).  But as they are minimized, if I want to switch to the 
>> window open
>> to the right computer, the right path and right credentials.
> For this case, I set the hostname, userid and CWD in the title of
> an xterm.
I do...
> In my eyes, security is something else. But you're correct that
> it is easier to make mistakes.
    Security is about information integrity as well as protection.
Even windows has implemented integrity labels.

>> This means when sudo or pam clears out my host, I have typed the 
>> wrong commands
> In /etc/bashrc I always set the prompt: PS1='\u@\h:\w\$ '
> You can even set it to something like this:
> PS1='${REMOTEHOST:-$(hostname -s)}->\u@\h:\w\$ '
> Or:
> PS1='${REMOTEHOST}${REMOTEHOST:+->}\u@\h:\w\$ '
> The last one prints the contents of REMOTEHOST and an arrow
> if REMOTEHOST is set. And nothing if not.
IF REMOTEHOST is set... when sudo gets run.. that is cleared by default
on my system.

In fact, I  had to setup REMOTEHOST and DISPLAY in pam_env... which
some are now using "mid-session" to reinit the env -- which hoses
REMOTEHOST and DISPLAY usually -- since they are only available at
initial remote access.

>>    I'm using executables as a term for both.  Shell scripts,
>> functions, java, perl, compiled
> Whence the confusion. For me, executables are scripts and compiled
> source code files located in a 'bin' directory.
    I have scripts and executables in my bin dir.  I write little in
C/C++ these days...

>>  Problems lately have come from
>> scripts that set flags if something has already been done. 
> And with flags you mean files? The standard or default command
> completion files in /etc/bash_completion.d do not set flags to
> indicate something has been done.
    No,... like set an envvar readonly to indicate that env-read-only
functions are defined... they both propagate the same way.
(aliases don't though)...
>> My distro tried not to overwrite user changes by looking at what 
>> flags are set.
> Something, you've developed yourself I gather?
    Well my own user changes, yes, but I worked with the distro folks to 
sure they didn't overwrite my changes... I try to layer mine on top of 

>> causes multiple types of failures -- including DISPLAY and REMOTEHOST 
>> being
> Those can be added to sudoers to be included in the list of
> variables to be propagated.
    Yeah, but the way my distro had pam_env setup, it cleared them by 
especially the re-running of pam_env... when the remote stuff wasn't

> Kind regards, Edgar Matzinger.
> _

ditto... & cheers!


More information about the sudo-users mailing list