Início / unix / Perguntas / 510855
Accepted
Rakib Fiha
Asked: 2019-04-06 22:29:39 +0800 CST

sudo sem sudo, implicando sudo no script

  • 772

Eu fiz alguns scripts contendo algumas funções que, por design, precisam de permissão sudo. Eu adicionei esses caminhos em .bashrcfor Linuxe .bash_profilefor MacOSpara que ele possa ser chamado de qualquer lugar.

Mas não quero que o usuário digite sudotoda vez que quiser chamar essas funções de script. Existe alguma maneira que eu possa implicar sudode uma maneira que sempre que essas funções forem chamadas, o terminal assumirá que está sendo chamado pelo usuário root?

Acho que devo apenas adicionar sudo -ino início do script ou talvez cada função? Ou existe alguma outra maneira alternativa de implicar sudo? Além disso, seria ótimo saber se você acha que seria terrível ou perigoso sugerir sudo e se não é recomendado.

Um exemplo de dangerous-functionscript que contém algumas funções que estou tentando realizar sem especificarsudo 

#!/bin/bash
start-one()
{
    ## do dangerous stuff with sudo
    systemctl start dangerous.service
}

start-two()
{
    systemctl start dangerous1.service
}

start-launchwizard()
{
    systemctl start dangerous2.service
}

## Calling functions one by one...
"$@"

Eu não quero chamá-los por sudo dangerous-function start-one eu só quero chamá-los com, dangerous-function start-onemas ainda obter o mesmo resultado que o anterior.

bash shell

2 respostas

  1. Best Answer

    O "$@"será expandido para a lista de argumentos de linha de comando, citados individualmente. Isso significa que se você chamar seu script com

    ./script.sh start-one

    ele será executado start-onenesse ponto (que é sua função). Isso também significa que invocá-lo como

    ./script.sh ls

    iria rodar ls.

    Permitir que um usuário invoque o script usando sudo(ou usando sudodentro do script) permitiria que ele executasse qualquer comando como root, se tivesse sudoacesso. Você não quer isso.

    Em vez disso, você precisaria validar cuidadosamente os argumentos da linha de comando. Talvez algo como

    foo_func () {
    # stuff
    printf 'foo:\t%s\n' "$@"
}

bar_func () {
    # stuff
    printf 'bar:\t%s\n' "$@"
}

arg=$1
shift

case $arg in
    foo)
        foo_func "$@" ;;
    bar)
        bar_func "$@" ;;
    *)
        printf 'invalid sub-command: %s\n' "$arg" >&2
        exit 1
esac

    Teste:

    $ sh script.sh bar 1 2 3
bar:    1
bar:    2
bar:    3

    $ sh script.sh baz
invalid sub-command: baz

    Isso seria mais seguro de usar com sudo, mas você ainda não desejaria executar nada que o usuário fornecesse a você dentro de suas várias funções diretamente sem limpar a entrada. O script acima faz isso restringindo o usuário a um conjunto específico de subcomandos, e cada função que manipula um subcomando não executa eval, ou sourceseus argumentos.

    Deixe-me dizer isso novamente com outras palavras: O script não tenta, e não deve, tentar executar a entrada do usuário como código de forma alguma . Ele não deve tentar descobrir se um argumento corresponde a uma função no ambiente atual que ele pode executar (funções podem ter sido colocadas lá pelo ambiente de chamada) e não deve executar scripts cujos nomes de caminho foram fornecidos na linha de comando etc.

    Se um script estiver executando tarefas administrativas, eu esperaria ter que executá-lo com sudo, e não gostaria que o próprio script me pedisse minha senha, especialmente se for um script que eu queira executar de forma não interativa ( por exemplo, de um cron job). Ou seja, um script que executa tarefas administrativas que exigem privilégios de root deve (IMHO) ser capaz de assumir que está sendo executado com os privilégios corretos desde o início.

    Se você quiser testar isso no script, você pode fazê-lo com

    if [ "$( id -u )" -ne 0 ]; then
    echo 'please run this script as root' >&2
    exit 1
fi

    Em seguida, ele move a decisão de como executar o script com privilégios de root para o usuário do script.

    • 5

  2. Você pode adicionar seu script /etc/sudoers(de preferência usando `visudo) para que seja acessível ao usuário.

    user ALL= /path/to/script

    Então o usuário poderá executar path/to/scriptsem sudo.

    • 2

relate perguntas