shell script: use o sudo dentro dele vs rode com o sudo?

Question

Ao escrever um script de shell, no qual alguns, mas não todos os comandos nele, precisam de privilégios de superusuário, devo

• adicione o sudo aos comandos que precisam de privilégios de superusuário, e execute o script de shell sem sudo, ou

• não adicione o sudo aos comandos que precisam de privilégios de superusuário, mas execute o shell script com o sudo?

Na segunda maneira, eu só precisarei fornecer minha senha uma vez, mas todos os comandos no script serão executados com privilégios de superusuário, incluindo aqueles comandos que não precisam.

Da primeira maneira, eu preciso fornecer minha senha várias vezes para diferentes comandos sudo, enquanto os privilégios de superusuário são concedidos apenas aos comandos que precisam deles.

Da preocupação de segurança, a primeira maneira é melhor. Por conveniência, a segunda maneira é melhor.

1. Eu estive pensando em adotar o primeiro caminho. Então eu tenho que negociar com a inconveniência de fornecer minhas senhas para múltiplos sudo comandos no script de shell.

2. Stephen Harris escreveu :

   A well written script would detect if it was running with the right permissions and not call sudo at all, but there's a lot of bad scripts

   Então, devo usar o segundo caminho? Se sim,

   • como posso escrever "o script detectaria se ele estava sendo executado com as permissões corretas e não chamaria o sudo"?

   • como posso melhorar sua segurança para evitar o problema de conceder privilégios de superusuário a comandos que não precisam deles quando estão em execução o script com sudo?

3. Essa abordagem simples teria o melhor de ambas as abordagens: adicione sudo aos comandos que só precisam dele, e execute o script com ou sem sudo dependendo se eu quero conveniência ou segurança? Essa abordagem tem algum problema?

Obrigado.

    

Answer 1

Para resolver seu primeiro problema:

how can I write "script would detect if it was running with the right permissions and not call sudo at all"?

Existe uma verificação simples e POSIX para root:

#!/bin/sh

AmIRoot()
{
    [ "$(id -u)" -eq 0 ]
}

Como alternativa, no Bash, mais codificadores orientados a desempenho podem usar:

#!/bin/bash

AmIRoot()
{
    ! (( ${EUID:-0} || $(id -u) ))
}

Note que encapsulou intencionalmente o código em funções para reutilização.

Para resolver seu segundo problema:

how can I improve its security to avoid the problem of giving superuser privileges to commands which don't need them when running the script with sudo?

Você não pode fazer muito sobre isso. Pelo menos nada vem à minha mente. Se eu vi o roteiro, posso ter sugestões. Mas como você não o incluiu na sua pergunta ... Se você executar o script inteiro com sudo ou como root , não vejo como controlar isso.

Para abordar o comentário:

What do you think of "use sudo inside it vs run it with sudo"

Em meus scripts, eu costumo prosseguir com a última abordagem, mas isso não significa necessariamente que eu recomendo para você. Porque depende de quem o script é destinado - para root apenas; para o usuário, principalmente com a exceção de alguns usuários terem sudo direitos; você teria que incluir literalmente o seu script na pergunta para eu poder responder com qualquer valor.

    

Answer 2

Acho que posso responder isso.

So should I use the second way?

Não há motivos para você ter um problema aqui, é por isso:

Se houver apenas um comando que precisa ser executado como root, run seu programa como root ou sudo porque sudo dentro de seu script é o caminho mais longo. Você esqueceu que os programadores são preguiçosos?

Se você precisar de muitos comandos run as root , execute-o como root ou sudo .

how can I improve its security to avoid the problem of giving superuser privileges to commands which don't need them when running the script with sudo?

Se outros usuários precisarem run do seu programa, configure sudo para eles porque sudo é muito personalizável e atenderá às suas necessidades.

Veja um exemplo com sudo :

Sempre use visudo ao editar o arquivo sudoers .....

kate ALL=(ALL) NOPASSWD: /usr/local/bin/script ARG1 ARG2

sudo também é ótimo para mudar usuários dentro de seu programa / script aqui está uma linha de um dos meus scripts:

sudo -i -u "$user" user="$user" CURRENTDIR="$CURRENTDIR" BASHRC="$BASHRC" bash <<'EOF'

how can I write "script would detect if it was running with the right permissions and not call sudo at all"?

link
how-do-i-determine-if-a-shell-script -executando com permissões de root

bash/sh:

#!/bin/bash
# (Use #!/bin/sh for sh)
if [ 'id -u' = 0 ] 
then
        echo "I AM ROOT, HEAR ME ROAR"
fi

csh:

#!/bin/csh
if ( 'id -u' == "0" ) 
then
        echo "I AM ROOT, HEAR ME ROAR"
endif

#!/bin/bash
if [[ $EUID -ne 0 ]]; then
  echo "You must be a root user" 2>&1
  exit 1
else
  mount /dev/sdb1 /mnt/disk2
fi

EDIT a pedido do cavalheiro @terdon:

Pense no seu roteiro dessa maneira ...

É um script público (outras pessoas que você vai usá-lo) O que o script faz? Diz a você o tempo? Ou atualiza o iptables em 200 sistemas? Se você usá-lo, ele é relacionado ao trabalho / profissional ou é para uso pessoal?

Você só precisa saber antecipadamente em que consiste seu grupo de usuários.

Se for written para dar ou vender para administradores, mesmo assim, por que o script não deve ser executado como root ?? Que mal pode fazer?

Scripts / programas reais são executados frequentemente como o usuário privilegiado e ninguém menciona que isso não é problema, mas quando programadores, principalmente novatos como eu falam sobre essas coisas, então é uma ameaça real à segurança ..... o que o cara sua postagem que você está falando está tentando dizer, embora não elegantemente, é que algumas pessoas olham para o controle que você tem do system e do seu código .... você define arquivos com mais permissões do que você vai usar, você tem todas as verificações em sua lógica ou programador talentoso vai ver perigos em seu código apenas olhando para ele?

Se você usa code needs root , use sudo e, se houver muitos, basta executá-lo como root. ...... minha resposta termina aqui ufa