Eu tenho um script que me dá um controle refinado sobre o brilho da luz de fundo e exige que sudo seja executado. É essencialmente isto:
backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight
e vive em ~/bin/backlight-adjust . O script precisa de sudo privileges, porque tee $backlight está gravando em um local privilegiado. Então, ele falhará se não for executado com sudo .
Essa abordagem tem um problema, porque não posso executar apenas sudo backlight-adjust , porque ~/bin não está no $PATH no ambiente sudo , apenas no meu ambiente. Então eu tenho que executar sudo env "PATH=$PATH" backlight-adjust ou algo similar.
Como alternativa, eu poderia ter escrito assim:
backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight
e solicite a senha.
A segunda abordagem funciona melhor para mim porque não preciso lembrar de digitar sudo; isso me perguntará. E eu posso manter meu $PATH intacto. Isso parece mais conveniente no geral, mas há alguma razão pela qual eu não deveria fazer isso da segunda maneira?
(Estou rodando o Xubuntu 14.04 e meu shell é o GNU bash 4.2.45, se isso faz diferença.)
Pessoalmente, eu usaria uma abordagem diferente. Faça um alias para o seu script. Adicione esta linha ao seu ~/.bashrc (ou equivalente em outros shells)
alias backlight-adjust='sudo ~/bin/backlight-adjust'
Dessa forma, você não precisa se preocupar em lembrar de executá-lo com sudo e não precisa adicionar sudo ao script. Ele será completamente transparente para você e simplesmente solicitará sua senha quando você tentar executar backlight-adjust .
Não consigo ver por que isso pode estar incorreto - embora eu prefira que os comandos não me perguntem coisas, para que eles sejam programáveis. Você pode ajustar /etc/sudoers para que sudo funcione sem uma senha.
Mas ... por que não adicionar
chgrp one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness
chmod g+w /sys/class/backlight/acpi_video0/brightness
no seu /etc/rc.local e esqueça o sudo ?
(No Ubuntu, se você for capaz de usar sudo você está no grupo sudo , então você pode usar chgrp sudo /sys... e ficar feliz com isso.)
Como alternativa, você pode adicionar
Defaults env_keep +="PATH"
para o seu arquivo /etc/sudoers .
Você define sudo backlight-adjust, porque ~ / bin não está no $ PATH no ambiente sudo
Então, por que depender disso?
Eu acho que você deveria apenas mudar essa linha para /home/user/bin/backlight-adjust e isso funcionará.
Mas eu realmente gostaria da solução de Terdon de usar um alias também. Ou você pode colocar seu script em /usr/bin/ e estará disponível para todos os usuários (incluindo root)
Não é possível dar uma regra geral ... se o script / programa foi projetado para fazer alguma reconfiguração (por exemplo, uma impressora) e ser chamado por usuários comuns, é necessário. Caso contrário, eu deixaria bem o suficiente sozinho: se um usuário regular o executa, apenas falha (seja como resultado de uma verificação explícita ou apenas porque não é permitido fazer algo).
Privilégios elevados devem ser distribuídos com parcimônia, se for o caso. Mudar para um privilégio mais alto é complicado, é melhor deixar isso para os especialistas (por exemplo, sudo(1) ).
Eu pessoalmente uso algo como ${SUDO} em meus scripts, para que o chamador possa configurá-lo, se necessário, ou ${SUDO:-sudo} para usá-lo por padrão.
No seu caso específico, estou com a resposta aceita.
Coloque o script (sem o sudo ) em um local adequado para todo o usuário, como /bin , e faça isso:
sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust
Isso funciona configurando o sinalizador setuid, o que significa que ele sempre será executado como o proprietário do arquivo. Para mais detalhes, leia o link . Eu realmente não sei muito sobre como isso funciona, eu só encontrei o googling baseado em algo que eu pensei ter lido alguns anos atrás.
Tags sudo bash shell-script