4 min read

Elévation des droits

Confusion entre droit sudo , root et login shell root

Au boulot ou même chez moi quand je dois modifier des fichiers qui se trouvent à la racine, changer les droits, ou simplement éditer des fichiers de configuration, je prends les droits root.

Ça m’évite de taper sudo à chaque fois que j’utilise vi, au bout d’un moment c’est chiant.

/!\Spoiler Alert digression en vu !! /!\

Hier, je reviens sur un problème qui me turlupine, et dont je n’ai pas trouvé la solution: un agent qui ne s’exécute pas correctement, et qui ne communique plus avec son serveur…

Je l’avais pourtant installé correctement, il a communiqué correctement également, puis de toute évidence, il s’est produit un évènement, depuis il ne fonctionne que partiellement, sans que j’arrive à identifier cet évènement précisément. Et il n’y a pas de documentation.

Dans le doute, je vérifie dans la console, si d’autres établissements ont des debian, si j’en trouve cela signifie que l’agent fonctionne, et c’est le cas.

J’en fais part à mon collègue, je constate que nous procédons de la même manière, je décide de récupérer un package à jour (sait-on jamais), et là patatra !! On en revient enfin à notre sujet initiale.

su root

La confusion n’est pas évidente au premier abord, pensant être root car je pouvais travailler tranquillement je lance un :

dpkg -i mon_agent.deb

Stupeur (enfer et damnation !!) Quelle est cette diablerie !

dpkg: warning: 'ldconfig' not found in PATH or not executable.
dpkg: warning: 'XXXXXX' not found in PATH or not executable.
dpkg: 2 expected program(s) not found in PATH or not executable.
NB: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.

Je ne vais pas vous faire poireauter. Simplement, la manière dont j’utilise root me donne effectivement ses droits, et on parle bien de droits, mais pas de son $PATH.

Je ne me connecte pas en tant que root, je prends simplement ses droits, et ce n’est pas pareil. Je conservais mon $PATH, bon …

Ce n’est pas dramatique, mieux vaut avoir moins de droits, surtout en production.

Maison ≠ Travail

Partant du principe qu’au travail, je ne suis pas à la maison, j’ai cloisonné mes utilisateurs au travail ce n’est pas plus mal, mais c’est une notion que j’avais oublié.

Mes utilisateurs en environnement de prod ne peuvent pas tout faire n’importe comment. Et c’est tant mieux.

A la maison , ordinatous est directement dans le groupe sudo , dans l’article Guide de survie Part2, on voit que ordinatous n’est pas dans /etc/sudoers mais peut invoquer sudo.

login shell et environnement utilisateur

Un autre notion qui est facile à démontrer, il suffit de lire l’enchaînement de commande:

sudo su
[sudo] Mot de passe de ordinatous : 
root@gallyair:/home/ordinatous/lithium/public# $PATH
bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin: Aucun fichier ou dossier de ce type
root@gallyair:/home/ordinatous/lithium/public# exit
exit
ordinatous@gallyair:~/lithium/public$ sudo -i
root@gallyair:~# $PATH
-bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin: Aucun fichier ou dossier de ce type
root@gallyair:~# exit
déconnexion
ordinatous@gallyair:~/lithium/public$ sudo su
[sudo] Mot de passe de ordinatous : 
root@gallyair:/home/ordinatous/lithium/public# $PATH
bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin: Aucun fichier ou dossier de ce type
root@gallyair:/home/ordinatous/lithium/public#

Au premier sudo su , j’entre mon mot de passe , on voit le chemin du PWD, puis sudo -i pas de mot de passe, et on voit que le pwd est dans root.

Voilà sudo -i est très dangereux surtout aux mains d’un gogol mégalo qui ne veut absolument pas que ses actions ne soient tracées; et je pense a quelqu’un en particulier; quand je le voit faire, je flippe pour les machines.

Différence entre debian et ubuntu

Un vieux sujet qui a au moins 9 ans, d’ailleurs l’exemple de ifconfig est obsolète maintenant c’est ip tout simplement, et ça a finalement fini chez les users.

Comparaison Debian (gauche) et Ubuntu (droite):

$ ifconfig                                 $ ifconfig
bash: ifconfig: command not found          eth0     Link encap ...
$ which ifconfig                           $ which ifconfig
$                                          /sbin/ifconfig

Then as superuser:

# ifconfig                                 # ifconfig
eth0      Link encap ...                   eth0     Link encap ...
# which ifconfig                           # which ifconfig
/sbin/ifconfig                             /sbin/ifconfig

Furthermore:

# ls -l /sbin/ifconfig                     # ls -l /sbin/ifconfig
-rwxr-xr-x 1 root root 68360 ...           -rwxr-xr-x 1 root root 68040 ...

It seems to me the only reason I cannot run ifconfig without superpowers on Debian is that it’s not in my path. When I use /sbin/ifconfig it does work.

Is there any reason I should not add /usr/local/sbin:/usr/sbin:/sbin to my path on Debian? This is a personal computer, I am the only human user.

Source

/etc/profile should include sbin in PATH

Vieux sujet qui a bientôt 25 ans .

Mailing list debian

Filesystem Hierarchy Standard

Et ces vieux sujets de $PATH et de droits découlent de ce sujet:

Filesystem Hierarchy Standard