Usando o sudo dentro de um script

Question

Considera-se boa ou má prática usar o comando sudo dentro de um script de shell? Uma vantagem é que, se o usuário executar o script como não-raiz, ele será solicitado a fornecer uma senha por demanda, em vez de a falha do script. Por outro lado, se o usuário tiver executado recentemente um comando com sudo, o script implicitamente executará comandos como root, o que pode não ser o que o usuário espera.

Aqui está um exemplo:

$ cat foo1
#!/bin/sh
sudo bar #implicit sudo
$ ./foo1

$ cat foo2
#!/bin/sh
bar
$ sudo ./foo2 #explicit sudo

    

Answer 1

Usar o sudo é sempre uma boa prática. No entanto, existem maneiras de tornar o uso do sudo melhor. Um dos métodos seria permitir explicitamente que um comando específico fosse executado com privilégios elevados.

O seguinte permitiria que apenas pessoas do grupo "usuários" executassem o comando foo1 sem uma senha.

%users ALL=(ALL) NOPASSWD: /full/path/to/foo1

No entanto, isso não permitiria a execução de foo2 em seu exemplo acima, a menos que um usuário tenha digitado a senha correta.

Além disso, muitas vezes é melhor configurar o sudo para exigir a senha do usuário e não a senha raiz (estou esquecendo a opção de configuração neste momento) e não ter entradas que permitam aos usuários aumentar seus privilégios, como:

ALL ALL=(ALL) ALL

ou

%users ALL=(ALL) ALL

O usuário de um grupo de rodas ou um grupo semelhante para escalonamento de qualquer comando é uma boa prática. No final, é melhor que a senha raiz seja trancada em um cofre, para nunca ser usada por ninguém (nunca), a menos que o material fedorento atinja o ventilador.

    

Answer 2

/ breve opinião

Pessoalmente, acredito que, se você não estiver olhando para o script antes de executá-lo, quaisquer efeitos colaterais que ocorram são principalmente sua culpa (comandos que são executados com sudo , por exemplo), mas ao mesmo tempo vez, sei que pode ser difícil analisar e criar um script inteiro todas as vezes. No geral, prefiro uma estratégia híbrida em que posso equilibrar conveniência e segurança.

/ opinião final

Lembre-se sempre que você pode executar sudo -k antes de chamar um script para solicitar a primeira sudo implícita a solicitar sua senha, a menos que ela também seja executada após cada comando sudo dentro do script APENAS solicitar a primeira chamada para sudo .

Existem algumas maneiras de realizar um script seguro e sã usando o sudo apenas quando necessário, um pouco mais complicado do que outras. Este post descreve alguns exemplos / opções que vou expandir mais. link

Você pode executar o script inteiro com sudo , que, como você descreveu, é "explícito", mas isso também significa que TODOS os comandos do script são executados como raiz e, se não estiverem bem escritos, ou você esqueceu que $USER pode mudar dentro do script para root e você precisa usar $SUDO_USER , então você pode acabar em um mundo de dor. Eu acidentalmente fiz isso no passado e coisas terríveis e estranhas aconteceram e então você (e eu) acabamos guardando seus scripts com if [ $EUID -eq 0 ]; then echo "Don't run as root!"; fi ou o oposto -gt 0 e você tem que lembrar de colocar um dos guardas em cada roteiro que você escreve (ou aprenda ferramentas de gerenciamento de configuração como SaltStack / Puppet / Chef que podem automatizar um pouco disso para você).

sudo somescript.sh

A opção que eu prefiro usar é executar TEMPORARIAMENTE executar sudo com um tempo de cache infinito, para que nenhum outro comando sudo executado por você requeira um novo prompt (ou possivelmente qualquer um dependendo de como você o configurou). O ideal seria colocar uma função devidamente automatizada e testada (ou incluir seu script "cache_sudo.sh") no início de seus scripts e depois remover o tempo limite infinito ativando sudoers.d arquivo assim que o script sair (morto / acabado / erro) usando trap e, em seguida, sudo -k para expirar a sessão / token depois de remover o arquivo. Veja esta resposta para um exemplo de teste e adicione o arquivo somente se for válido.

Esta é a versão manual, não coloque isso no seu script.

sudo visudo -f /etc/sudoers.d/infinite_cache_myuser
#Add next line to the file
Defaults:YOUR_USER_NAME timestamp_timeout=-1

Os benefícios do cache infinito estão dentro do seu script e você pode elevar APENAS os comandos que requerem root com o sudo, sem ter que "downgrade" TODOS os outros comandos usando su $MY_REGULAR_USER some_command ou sudo -u $MY_REGULAR_USER some_command para o comando EVERY SINGLE. (Eu realmente não gosto de código desnecessariamente repetido para descartar privilégios se houver uma maneira menos dolorosa e não totalmente insegura de escrevê-la para elevar apenas quando necessário).

Uma forma de diminuir o código repetido seria definir um "prefixo" de comando curto que adiciona sudo ou su $MY_USER , dependendo se o script será executado com sudo ./myscript.sh ou ./myscript.sh com sudo interno.

Você pode escrever uma regra sudoers para permitir a execução do script de destino com sudo e nenhum prompt de senha, mas acho que essa é uma idéia tão ruim quanto a primeira opção, só ajuda um pouco se você quiser executar o sudo de uma tarefa cron executada como um usuário não raiz, mas que precisa alterar algo que exija raiz ou outro usuário, embora seja necessário ler man sudoers para aprender a sintaxe para permitir que um usuário represente outro usuário.

# Customize line below and add to /etc/sudoers or /etc/sudoers.d/my_script_runner
YOUR_USER_NAME ALL=(ALL:ALL) NOPASSWD:/abs/path/to/your/script

Você também pode permitir o sudo sem senha apenas para os comandos que o exigem, o que permite executar o script como não-raiz e ainda acessar esses comandos.

YOUR_USER_NAME ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get update
YOUR_USER_NAME ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get upgrade
YOUR_USER_NAME ALL=(ALL:ALL) NOPASSWD:/usr/bin/updatedb

Esta opção é provavelmente minha segunda escolha por trás do truque do cache infinito. A desvantagem é que você está editando o arquivo sudoers toda vez que encontra um novo comando que precisa de root, em vez de apenas poder adicionar sudo na frente do comando em seu script. A vantagem é que você está permitindo apenas sudo sem senha, quando necessário, e você ainda pode exigir uma senha para outros comandos sudo , ficando assim muito mais seguro.