Como resolver a "permissão negada" ao usar o sudo com o redirecionamento no Bash?

Ao usar o sudo para permitir edições em arquivos, recebo regularmente 'permissão negada'.

Por exemplo, meu mouse está nervoso e lento, então eu quero desativar a pesquisa:

sudo echo "options drm_kms_helper poll=N">/etc/modprobe.d/local.conf

Sou solicitada uma senha e, em seguida, obtenho:

bash: /etc/modprobe.d/local.conf: Permission denied

Então, tentei fazer uma alteração temporária para desativar a pesquisa usando:

sudo echo N> /sys/module/drm_kms_helper/parameters/poll

Mais uma vez, o sistema respondeu com:

bash: /sys/module/drm_kms_helper/parameters/poll: Permission denied

Alguma ideia?

O redirecionamento de saída (via >operador) é feito pelo shell, não pelo eco . Você precisa fazer login como root

sudo -i

Então você pode usar o redirecionamento

echo N> /sys/module/drm_kms_helper/parameters/poll

Caso contrário, você pode executar o bash string com o sudo

sudo bash -c "echo N> /sys/module/drm_kms_helper/parameters/poll"

O redirecionamento de saída é feito pelo shell a partir do qual o comando foi chamado . Então, dividindo tudo em bits, aqui está o que está acontecendo *:

• shell chama sudo echo "options drm_kms_helper poll=N", que executa sudocomando com echo "options drm_kms_helper poll=N"linha de comando

• sudo pede uma senha, abre o shell do superusuário e chama echo "options drm_kms_helper poll=N", que executa o echocomando passando-o"options drm_kms_helper poll=N"

• echo, executando com rootprivilégios, imprime a string na saída padrão.

• echoO comando termina, o shell do superusuário sai, sudotermina

• o shell do qual o comando foi chamado coleta a saída e tenta redirecioná-la para /etc/modprobe.d/local.conf, que é gravável apenas pela raiz. Ele recebe o erro "permissão negada".

Para formas de corrigir isso, consulte a resposta @shantanu.

(*) - enquanto a sequência acima ajuda a entender por que o comando falha, na realidade as coisas acontecem um pouco fora de ordem: o shell original percebe o redirecionamento e tenta abrir o arquivo para gravação antes de chamar o sudo ...comando. Ao abrir o arquivo falha, o shell nem chama o comando que deveria escrever no arquivo (obrigado a @PanosRontogiannis por apontar isso).

Aqui está um teste rápido:

$ touch ./onlyroot.txt
$ sudo chown root:root ./onlyroot.txt
$ sudo bash -c "whoami | tee who.txt" > onlyroot.txt
bash: onlyroot.txt: Permission denied

No teste acima, whoami | tee who.txtcriaríamos um arquivo chamado who.txtcontendo a palavra "raiz". No entanto, quando o redirecionamento de saída falha no shell de chamada, o arquivo "who.txt" também está ausente porque o comando não foi chamado.

Adicionando à resposta de Shantanu:

... Ou você pode usar um teecomando como este:

sudo tee /sys/module/drm_kms_helper/parameters/poll <<<10

ou se for a saída de um comando:

echo 10 | sudo tee /sys/module/drm_kms_helper/parameters/poll

Uma abordagem que não vi mencionada aqui é simplesmente executar toda a linha de comando em seu próprio shell. A sudoprópria página de manual fornece um exemplo dessa abordagem:

Para fazer uma lista de uso dos diretórios na partição / home. Observe que isso executa os comandos em um sub-shell para fazer o redirecionamento de CD e arquivo funcionar.

$ sudo sh -c "cd /home ; du -s * | sort -rn > USAGE"

Outra opção é usar um arquivo temporário. Isso é útil em um script bash.

temp=$(mktemp)
echo "Hello, world!" > $temp
sudo cp $temp /etc/wherever

sudo dd of=

Para adicionar como quiser:

echo inbytes | sudo dd of=outfile oflag=append conv=notrunc

ou para recriar o arquivo do zero:

echo inbytes | sudo dd of=outfile

Vantagens:

• melhor do que teedesde nenhum /dev/nullredirecionamento
• melhor do shque nenhuma sub-camada explícita (mas implícita para o redirecionamento)
• ddpossui muitas opções poderosas, por exemplo, status=progresspara ver o progresso da transferência

Funciona porque o sudo encaminha o stdin para o comando.