Os scripts que requerem o sudo falham se não o tiverem, ou usam o sudo e o prompt?

Eu tenho um script que me fornece controle refinado sobre o brilho da luz de fundo e requer sudoa execução. É essencialmente isso:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

e vive em ~/bin/backlight-adjust. O script precisa de sudoprivilégios, porque tee $backlightestá gravando em um local privilegiado. Portanto, falhará se não for executado sudo.

Essa abordagem tem um problema, porque não posso simplesmente executar sudo backlight-adjust, porque ~/binnão está $PATHno sudoambiente, apenas no meu ambiente. Então eu teria que correr sudo env "PATH=$PATH" backlight-adjustou algo parecido.

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 me lembrar de digitar sudo; isso vai me levar. E eu posso manter minha $PATHintacta. Isso parece mais conveniente no geral, mas há alguma razão pela qual não devo fazê-lo da segunda maneira?

(Estou executando 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 reservatórios)

alias backlight-adjust='sudo ~/bin/backlight-adjust'

Dessa forma, você não precisa se preocupar em lembrar de executá-lo sudoe não precisa adicioná sudo-lo ao script. Será completamente transparente para você e simplesmente peça sua senha ao tentar executar backlight-adjust.

Não vejo por que isso pode estar incorreto - embora eu prefira que os comandos normalmente não perguntem coisas para mim, para que possam ser escritas. Você pode ajustar /etc/sudoerspara que sudofuncione 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.locale esquecer sudo?

(No Ubuntu, se você pode usá- sudolo, você está no grupo sudo , para poder usá-lo chgrp sudo /sys...e ser feliz com ele.)

Como alternativa, você pode adicionar

Defaults        env_keep +="PATH"

para o seu /etc/sudoersarquivo.

Você declara o ajuste da luz de fundo do sudo, porque ~ / bin não está no $ PATH no ambiente sudo

Então, por que depender disso? Eu acho que você deveria mudar essa linha para /home/user/bin/backlight-adjuste ela funcionará.

Mas eu realmente gostaria da solução de Terdon de usar um pseudônimo também. Ou você pode colocar seu script /usr/bin/e ele estará disponível para todos os usuários (incluindo root)

Não é possível fornecer uma regra geral ... se o script / programa foi projetado para fazer alguma reconfiguração (por exemplo, uma impressora) e for chamado por usuários regulares, é necessário. Caso contrário, eu deixaria em paz o suficiente: se um usuário comum executá-lo, apenas falhe (como resultado de uma verificação explícita ou apenas porque não é permitido fazer algo).

Privilégios elevados devem ser concedidos com moderação, se houver. Mudar para privilégios mais altos é complicado, é melhor deixar para os especialistas (por exemplo, sudo(1)).

Eu pessoalmente uso algo como ${SUDO}nos meus scripts, para que o chamador possa configurá-lo, se necessário, ou ${SUDO:-sudo}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 o seguinte:

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 detalhes, leia http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Eu realmente não sei muito sobre como isso funciona, eu apenas o achei pesquisando com base em algo que eu pensei ter lido alguns anos atrás.