Como para um comando sudo que mantém todas as variáveis de ambiente

Question

Exemplo de comando é o seguinte, executado como um usuário normal

which python
/home/me/env/development/python 

porque o ambiente PATH contém um caminho que aponta para essa instância de python (em vez disso, aponta para /usr/bin/python ).

Eu quero ser capaz de executar um comando python com a variável de ambiente SAME, então

sudo which python

que retorna /usr/bin/python . Usando a opção -E dá o mesmo resultado.

Como posso executar um comando python com root-right, mas com as variáveis de ambiente preservadas. Eu não quero especificá-los todos com o comando sudo, e eu acho que para 'copiar' apenas as variáveis PATH devem ser suficientes.

Pergunta formulada em outras palavras: Como posso executar um comando python com sudo , que tem a mesma definição PATH que tenho atualmente como usuário normal?

    

Answer 1

Se você usar a opção "! env_reset" para desativá-la e " secure_path " não estiver definido no arquivo do sudoer, as opções "env_check" e "< em> env_delete "pode remover o PATH de ser isento de reset (ou seja, eles funcionam como entradas da lista negra).

Uma causa mais provável seria que um sistema / etc / bashrc ou seu próprio .bashrc estivesse redefinindo o PATH para algum valor padrão (e não adicionando ao caminho existente, conforme necessário).

No meu próprio "sistema" bashrc (que eu mantenho em / etc / local e é chamado após o sistema bashrc), eu me esforço em não sobrescrever o caminho passado com algumas funções definidas no login:

# used in _path_op below
function empty {
    [[ $# -lt 1 ]] && return -1
    [[ -f $1 && ! -s $1 ]] && return 0
    [[ -d $1 ]] && {
        local -a entries=("$1"/*)
        [[ ${entries[0]} == "$1/*" ]] && return 0
    }
    return 1
}

function _path_has_subpath { [[ ${!1} =~ (:$2:|^$2:|:$2$) ]] ; }

function _path_op {
    (($#<3)) && return 1        # 3rd arg is path to <X>pend
    local fmt="$1" pathname="$2"; shift 2
    while (($#)); do 
        [[ -d $1 ]] && ! empty "$1" && {
            _path_has_subpath "$pathname" "$1" || 
                eval "export $(set $pathname $1; eval "echo $fmt")"
        }
        shift; 
    done    
}

# called with name of path (ex. 'PATH' & one or more sub paths 
# each of these prepend an "assign FORMAT" to the passed-in PATHVAR + pathcomp
function _path_append  { _path_op '$1=\"${!1}:$2\"' "$@" ; }
function _path_prepend  { _path_op '$1=\"$2:${!1}\"' "$@" ; }
typeset -x  _path_append _path_prepend _path_has_subpath _path_op

Eu os chamo via:

_path_append PATH /opt/kde3/bin /usr/local/bin "$PATH_HOME/bin" 
_path_prepend PATH "$PATH_HOME/bin/lib"

Claro que se o problema está no bashrc da sua distro, você pode registrar um bug ...; -)

(isto assume que você não está chamando sudo com o "-i" que diz para começar com um novo ambiente).

FWIW, no começo e no fim dos meus vários arquivos profile e bashrc e env e seus sub-arquivos ... E nas versões da minha distro (tem que ser lido em uma atualização). Eu coloco estrofes de debug normalmente inativas. No começo:

[[ ${DEBUG:-} || -O /tmp/debug_local ]] && { 
  echo "(${#BASH_LINENO[@]:-""})entering $BASH_SOURCE ..." >&2;
  [[ -O /tmp/debug_local ]] && source /tmp/debug_local ; }

e final:

[[ ${DEBUG:-} || -O /tmp/debug_local ]] && { 
  echo "(${#BASH_LINENO[@]:-""})exiting $BASH_SOURCE ..." >&2;

Então, se eu precisar depurar um problema como este, eu posso tocar em / tmp / debug_local e ele irá criar logins barulhentos para todos os usuários do meu sistema (que geralmente é apenas eu no sistema em que estou usando).

Também de uso, se você ativar "-x" está mudando sua linha PS4:

#export PS4='>>\
[$(__age)]${BASH_SOURCE:+${BASH_SOURCE[0]}}#i\
${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}> '    

(O texto acima é uma linha, dividido com barras invertidas - também é um comentário, ou seja, descomente a utilização)