La redirección de salida la realiza el shell desde el que se ha invocado el comando . Entonces, dividiendo todo en bits, aquí está lo que está sucediendo *:
invoca shell sudo echo "options drm_kms_helper poll=N"
, que ejecuta el sudo
comando con la echo "options drm_kms_helper poll=N"
línea de comando
sudo solicita una contraseña, abre el shell de superusuario e invoca echo "options drm_kms_helper poll=N"
, que ejecuta el echo
comando pasándolo"options drm_kms_helper poll=N"
echo, ejecutándose con root
privilegios, imprime la cadena a su salida estándar.
echo
el comando termina, el shell del superusuario sale, sudo
termina
el shell desde el que se ha invocado el comando recopila el resultado e intenta redirigirlo /etc/modprobe.d/local.conf
, que solo se puede escribir por root. Se obtiene el error "permiso denegado".
Para conocer las formas de solucionar esto, consulte la respuesta @shantanu.
(*) - mientras que la secuencia anterior ayuda a comprender por qué falla el comando, en realidad las cosas suceden algo fuera de orden: el shell original nota la redirección e intenta abrir el archivo para escribir antes de invocar el sudo ...
comando. Cuando se abre el archivo, el shell ni siquiera invoca el comando que se suponía que debía escribir en el archivo (gracias a @PanosRontogiannis por señalar esto).
Aquí hay una prueba rápida:
$ touch ./onlyroot.txt
$ sudo chown root:root ./onlyroot.txt
$ sudo bash -c "whoami | tee who.txt" > onlyroot.txt
bash: onlyroot.txt: Permission denied
En la prueba anterior, whoami | tee who.txt
iba a crear un archivo llamado que who.txt
contiene la palabra "raíz". Sin embargo, cuando la redirección de salida falla en el shell de llamada, también falta el archivo "who.txt" porque no se invocó el comando.
saji@laptop:~$ sudo echo "Hi" [sudo] password for saji: Hi