Ubuntu-fr

sksbir

Mise en garde avec la commande sudo

jrev a mis le doigt sur un drôle de truc en applicant les instructions d'un tuto concernant le partage de connexion internet : ça se passe ici

Il semblerait que la commande suivante ne fonctionne pas:

sudo echo 1 >/proc/sys/net/ipv4/ip_forward

On récupère effectivement le message bash: /proc/sys/net/ipv4/ip_forward: Permission non accordée

D'apres ce que je sais d'unix, il semblerait que ça provienne de la façon dont le shell interprete tout ça:

On dirait qu'il analyse d'abord la commande 'sudo echo 1', puis redirige le résultat de cette commande vers le fichier ip_forward. Du coup, la redirection de la commande ne se ferait pas avec le privilège de root, ce qui explique le message d'erreur ( ce fichier systeme appartient à root)

J'ai donc voulu inhiber la 1ere interprétation de > en procédant de façon habituelle : mettre un \ devant le > :
sudo echo 1 \> /proc/sys/net/ipv4/ip_forward
Mais j'obtiens alors la réponse suivante:
1 >/proc/sys/net/ipv4/ip_forward

Et là, je pense qu'il se passe la chose suivante: Avec un \ devant le > le > n'est plus interprété comme redirecteur. Mais du coup, le > n'est jamais interprété comme redirecteur

ça n'est pas le cas avec la commande rsh par exemple:
rsh machinedistante echo TOTO \> /tmp/TITI
provoquera bien l'écriture du fichier TITI contenant le mot TOTO sur la machine machinedistante.
alors qu'un
rsh machinedistante echo TOTO > /tmp/TITI
provoquera un 'echo TOTO' exécuté à distance, et dont le résultat sera remonté dans le fichier local /tmp/TITI.

bref, si les spécialistes de la commande sudo veulent se pencher sur ce problème, en attendant , je conseille de passer par

sudo bash
"ma commande avec privileges root et redirection"
exit

dès qu'il y a une redirection dans la commande ( <,  > , >> , << )....

---

Les quadrirotors

pef

Re : Mise en garde avec la commande sudo

C'est plus simple en fait

echo est une commande "builtin", c'est-à-dire une commande interne à ton shell, pas un binaire à part dans un répertoire bin ou sbin :

loic@iron:~$ type echo
echo is a shell builtin

il faut donc invoquer le shell directement, en lui disant qu'il trouvera un truc à faire en paramètre avec -c :

loic@iron:~$ sudo  bash -c " echo 1 > /proc/sys/net/ipv4/ip_forward "
loic@iron:~$ sudo cat /proc/sys/net/ipv4/ip_forward
1
loic@iron:~$ sudo  bash -c " echo 0 > /proc/sys/net/ipv4/ip_forward "
loic@iron:~$ sudo cat /proc/sys/net/ipv4/ip_forward
0

echo n'existe que pour ton shell, si tu tente de l'exécuter directement avec sudo par exemple, il va le chercher dans le PATH, et ne pas le trouver.

Voilà, j'espère que c'est clair

Dernière modification par pef (Le 24/06/2005, à 19:33)

sksbir

Re : Mise en garde avec la commande sudo

@pef : je pense que tu vas devoir revoir ton analyse

Voici le contre-exemple :

echo 1 > TOTO
cat TOTO
1
ok ,jusque là, ça fonctionne : voici donc l'équivalent de echo 1, mais en utilisant une commande externe.
seulement...

sudo cat TOTO > /proc/sys/net/ipv4/ip_forward
bash: /proc/sys/net/ipv4/ip_forward: Permission non accordée

Et puis aussi, d'habitude, le message par rapport à une commande non trouvée c'est:
sdfsdf
bash: sdfsdf: command not found
sudo sdfsdf
sudo: sdfsdfsd: command not found

Dernière modification par sksbir (Le 24/06/2005, à 20:01)

---

Les quadrirotors

effraie

Re : Mise en garde avec la commande sudo

et avec sudo -s ?

---

400iso.net
[Trops de chefs, pas assez d'indiens]

coxx

Re : Mise en garde avec la commande sudo

Un

sudo su
echo 1 >/proc/sys/net/ipv4/ip_forward
exit

devrait faire l'affaire pour régler les problèmes.

Dernière modification par coxx (Le 24/06/2005, à 20:47)

---

Monsieur K, de la chanson française parigote indépendante qui frappe fort !

Clips, paroles et sons disponibles sur le myspace de Monsieur K

pef

Re : Mise en garde avec la commande sudo

Un

sudo su
echo 1 >/proc/sys/net/ipv4/ip_forward
exit

devrait faire l'affaire pour régler les problèmes.

sudo -s est plus rapide pour obtenir un shell

pef

Re : Mise en garde avec la commande sudo

@pef : je pense que tu vas devoir revoir ton analyse

Voici le contre-exemple :

echo 1 > TOTO
cat TOTO
1
ok ,jusque là, ça fonctionne : voici donc l'équivalent de echo 1, mais en utilisant une commande externe.
seulement...

sudo cat TOTO > /proc/sys/net/ipv4/ip_forward
bash: /proc/sys/net/ipv4/ip_forward: Permission non accordée

Et puis aussi, d'habitude, le message par rapport à une commande non trouvée c'est:
sdfsdf
bash: sdfsdf: command not found
sudo sdfsdf
sudo: sdfsdfsd: command not found

Ca m'a l'air compliqué finalement cette histoire, sûrement une histoire de redirection par bash avant d'interpréter les commandes fournies, ou alors un truc avec les entrées/sorties standards

Un exemple : avec la commande tee, qui duplique la sortie standard sur un fichier :

loic@iron:/tmp$ cat TOTO |tee resultat
1
loic@iron:/tmp$ cat resultat
1
loic@iron:/tmp$

Là tu es d'accord que la sortie  de la commande est envoyée vers la sortie standard (affichage sur le shell) et dans le fichier resultat

Donc maintenant, quoique j'ajoute à la suite, le fichier resultat devrait de toutes manières recevoir une copie de la sortie grâce à tee :

loic@iron:/tmp$ rm resultat
loic@iron:/tmp$  cat TOTO|tee resultat > /proc/sys/net/ipv4/ip_forward
bash: /proc/sys/net/ipv4/ip_forward: Permission non accordée
loic@iron:/tmp$ cat resultat
cat: resultat: Aucun fichier ou répertoire de ce type

Et pourtant non ! la première commande (cat) n'est pas interprétée, sinon le fichier resultat existerait

De plus si cat n'avait pas le droit de lire /proc/sys/net/ipv4/ip_forward, c'est à lui de le dire, et pas à bash :

loic@iron:~$ cat /proc/sys/net/ipv4/ip_forward
0

Donc dans notre cas, avec l'erreur précédée par un bash:

loic@iron:/tmp$  cat TOTO > /proc/sys/net/ipv4/ip_forward
bash: /proc/sys/net/ipv4/ip_forward: Permission non accordée

Indique bien que c'est bash qui tente de lire le fichier, et non cat

C'est à mon avis un problème au niveau de bash, avant d'être un problème au niveau de sudo, j'essayerai d'approfondir ca demain matin

Et merci d'avoir relevé ce problème pour le moins intéressant

Dernière modification par pef (Le 24/06/2005, à 21:22)

sksbir

Re : Mise en garde avec la commande sudo

mmm, quand bash indique une permission non accordée, ça ne prouve pas que c'est dans la 1ere partie de ta commande que se trouve le probleme de permission.
Je pense que bash effectue une analyse complète de toute la commande, et traite d'abord les redirections : ça parait logique : il faut d'abord savoir où envoyer le résultat d'une commande avant d'exécuter la commande en question.
Donc bash tente d'abord d'ouvrir un canal en ecriture sur la redirection spécifiée. Comme il y a rejet, c'est toute la commande qui n'est pas exécutée.
A ce niveau, ce qui est anormal, c'est qu'on ne puisse pas indiquer que la redirection doit être englobée dans le périmètre de la commande sudo.
Le bash indiquée dans le message d'erreur est le processus père de la commande : c'est lui qui analyse et exécute toutes les commandes que tu peux passer dans une console donnée.
C'est donc bien normal qu'il n'ait pas le droit d'ouvrir le canal en écriture, et qu'il refuse donc d'exécuter toute la commande.

Je persiste à penser que le bug se situe dans l'analyse du caractère de redirection ">".

D'ailleurs, voici une commande qui vient confirmer mon hypothèse:
echo 1 |sudo tee /proc/sys/net/ipv4/ip_forward

Dernière modification par sksbir (Le 27/06/2005, à 01:46)

---

Les quadrirotors

pef

Re : Mise en garde avec la commande sudo

mmm, quand bash indique une permission non accordée, ça ne prouve pas que c'est dans la 1ere partie de ta commande que se trouve le probleme de permission.
Je pense que bash effectue une analyse complète de toute la commande, et traite d'abord les redirections : ça parait logique : il faut d'abord savoir où envoyer le résultat d'une commande avant d'exécuter la commande en question.
Donc bash tente d'abord d'ouvrir un canal en ecriture sur la redirection spécifiée. Comme il y a rejet, c'est toute la commande qui n'est pas exécutée.
A ce niveau, ce qui est anormal, c'est qu'on ne puisse pas indiquer que la redirection doit être englobée dans le périmètre de la commande sudo.
Le bash indiquée dans le message d'erreur est le processus père de la commande : c'est lui qui analyse et exécute toutes les commandes que tu peux passer dans une console donnée.
C'est donc bien normal qu'il n'ait pas le droit d'ouvrir le canal en écriture, et qu'il refuse donc d'exécuter toute la commande.

Je persiste à penser que le bug se situe dans l'analyse du caractère de redirection ">".

D'ailleurs, voici une commande qui vient confirmer mon hypothèse:
echo 1 |sudo tee /proc/sys/net/ipv4/ip_forward

c'est bien ce que j'ai dit

sksbir

Re : Mise en garde avec la commande sudo

ha ?, désolé, j'ai du perdre le fil alors...

Bref, ce qui compte, c'est de connaitre cette limitation de sudo, histoire de ne pas faire faire n'importe quoi.

---

Les quadrirotors