Risque d'ajouter /usr/sbin/ ?

Bonjour,
Je me posais la question suite à quelques échanges dans un autre post du forum de savoir si il était dangereux d’ajouter /usr/sbin et /sbin à son path d’utilisateur lambda ( mais qui agit en connaissance de cause ).
En effet, devoir taper le chemin entier n’est pas forcément commode, et de toute façon pour les opérations modifiant le système il faut être root.
Je voudrais le faire particulièrement pour les commandes ifconfig et iwconfig.
Si vous avez un avis quelconque sur la question, allez-y :smiley: .

[quote=“L0u!$”]Bonjour,
Je me posais la question suite à quelques échanges dans un autre post du forum de savoir si il était dangereux d’ajouter /usr/sbin et /sbin à son path d’utilisateur lambda ( mais qui agit en connaissance de cause ).
En effet, devoir taper le chemin entier n’est pas forcément commode, et de toute façon pour les opérations modifiant le système il faut être root.
Je voudrais le faire particulièrement pour les commandes ifconfig et iwconfig.
Si vous avez un avis quelconque sur la question, allez-y :smiley: .[/quote]Aucune idée pour d’éventuelles conséquences.
Si tu ne veux pas taper le chemin ni rajouter au path, fais toi des alias du genre alias iwconfig='/sbin/iwconfig' ça marche tout aussi bien.

[quote="L0u!$ "]Je voudrais le faire particulièrement pour les commandes ifconfig et iwconfig.[/quote]Juste pour de la “lecture” de config ou pour une “modification”? :unamused: (je pense que la question est importante, comme tu l’as souligné plus haut, ça ne sert à rien pour la modif… :wink: … tu n’auras pas pour autant les droits nécessaires…)

:smt006

[quote=“L0u!$”]Bonjour,
Je me posais la question suite à quelques échanges dans un autre post du forum de savoir si il était dangereux d’ajouter /usr/sbin et /sbin à son path d’utilisateur lambda ( mais qui agit en connaissance de cause ).[/quote]
Le risque est nul. Ce n’est pas vraiment dans la philosophie GNU/Linux que de se protéger des choses dangereuses en les cachant.
Au pire, une petite perte de perf pour les répertoires du PATH à vérifier en plus pour chaque appel de commande.

[quote=“eol”]
Si tu ne veux pas taper le chemin ni rajouter au path, fais toi des alias du genre alias iwconfig='/sbin/iwconfig' ça marche tout aussi bien.[/quote]
+1 et même, si tu es encore plus fainéant (comme moi), tu peux raccourcir au maxi tes alias. Pour l’exemple ci-dessus : iw :mrgreen:

[quote=“ricardo”]+1 et même, si tu es encore plus fainéant (comme moi), tu peux raccourcir au maxi tes alias. Pour l’exemple ci-dessus : iw :mrgreen:[/quote]Oui, c’est vrai mes alias sont aussi du genre du tien, je ne sais pas pourquoi je n’ai pas pensé à être fainéant pour cet exemple. :confused:
Excès de zèle …
Va falloir que je me surveille.

[quote=“ricardo”][quote=“eol”]
Si tu ne veux pas taper le chemin ni rajouter au path, fais toi des alias du genre alias iwconfig='/sbin/iwconfig' ça marche tout aussi bien.[/quote]
+1 et même, si tu es encore plus fainéant (comme moi), tu peux raccourcir au maxi tes alias. Pour l’exemple ci-dessus : iw :mrgreen:[/quote]
Fais gaffe iw est un programme qui existe et qui sert aussi à gérer le wifi.

Oui, tu as raison de le rappeler, il faut quand même vérifier si le raccourci de l’alias n’est pas déjà un prog.
Je n’avais donné ça que comme exemple.
En principe, je donne à mes alias des noms qui me parlent et le plus court possible.

C’est marrant parce que moi à part ll, la et l1, je n’en utilise aucun, tout ce fait avec l’auto-complètement.

Bon bah je crois que je m’en vais de ce pas ajouter sbin à mon path.
Merco de vos réponses! :smt023

Par contre, quelle est la commande qui permet de modifier le path sans le rajouter dans mon .zshrc ? Je veux dire une commande qui le change à demeure?

Salut,

Vous êtes vous posé la question de savoir pourquoi les développeurs n’ont pas pensé à vos solutions ? Ou alors ils ont trouvé des raisons de ne pas le faire ?
Ceci devrait être un réflexe à chaque fois que nous avons envie de modifier le comportement du système :slightly_smiling:

[quote=“ggoodluck47”]Salut,

Vous êtes vous posé la question de savoir pourquoi les développeurs n’ont pas pensé à vos solutions ? Ou alors ils ont trouvé des raisons de ne pas le faire ?
Ceci devrait être un réflexe à chaque fois que nous avons envie de modifier le comportement du système :slightly_smiling:[/quote]

Je pense qu’ils ont du se dire un truc dans le genre:

[quote]les commandes dans /usr/sbin ne sont normalement utilisables que par root.
Plus précisément elles ne sont utiles que pour root, et c’est même dangereux de laisser utiliser ces commandes par n’importe quel utilisateur du systeme.
Dans debian, les gérants du projet ont dû estimer que vu que ces commandes n’étaient utiles qu’à root, autant ne pas laisser les utilisateurs standard y avoir accès.[/quote]
Comme je le dis dans le post viewtopic.php?f=8&t=3548&start=200 .

Mais tu as raison, je vais aller chercher un peu de doc à ce sujet.

Bon, j’ai trouvé ça: pathname.com/fhs/

Qui nous dit [ section /sbin ]:

[quote]Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and
/usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the
system in addition to the binaries in /bin. Programs executed after /usr is known to be mounted (when there
are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs
should be placed into /usr/local/sbin.[/quote]
Pour les non anglophones:
Les utilitaires pour l’administration système ( et les autres commandes pour root seulement ) sont stockées dan /sbin, /usr/sbin et /usr/local/sbin [ ça tout le monde devait s’en douter ]. /sbin contient les binaires essentiels pour bouter, restaurer, et/ou réparer le système en plus des binaires de /bin . [Sachant qu’on peut mettre /usr sur une autre partition ] Les programmes éxecutés après qu’ /usr soit connu pour être monté ( lorsqu’il n’y a pas de problèmes ) sont généralement placés dans /usr/sbin. […]
Donc mon hypothèse était juste. En fait ils n’ont pas à se justifier de n’avoir pas mis */sbin dans le path. Ils auraient dû si ils avaient mis /sbin dans le path, car c’est moins logique ( à part pour 2 commandes, l’utilité n’est pas flagrante, sauf dans le cas d’une intégration dès le départ de sudo ( comme dans le cas d’Ubuntu ). Après reflexion, je crois que je vais faire comme vous, je vais juste ajouter 2 alias.

(Encore) Merci pour vos réponses.

Re,

Demandez vous combien de fois par jour vous faites des ifconfig ?

Quand on habite dans une résidence du CROUS où le signal WiFi fait ce qu’il veut, on doit “/etc/init.d/networking restart” au moins une dizaine de fois par jour…

faire ifdown ; ifup n’est pas plus simple?

EDIT: pour ton cas, c’est sûr, il te faut un alias.
Ou alors tu peux faire invoke-rc.d networking restart

J’ai pratiqué le ifdown && ifup pendant un moment mais je me suis lassé :slightly_smiling:
Blague à part, ça fonctionne aussi bien.

Si c’est pour utiliser ifconfig sans paramètre pourquoi ne pas passer par netstat ? Parce que si c’est pour faire des modifications elles ne seront pas possible sans avoir les droits root.

parce que ifconfig ne m’est que très peu utile. c’est surtout iwconfig qui me sert pour des problèmes d’associations wi-fi ( je n’utilise pas d’utilitaires graphiques ).

La politique de gestion des utilisateurs est faites pour des sytèmes hébergeant des centaines d’utilisateurs et où il y a 15-30 personnes en même temps sur une machine. Être en général seul sur sa machine peut permettre des écarts. Même si une machine unix, on peut changer son PATH et mettre sbin et /usr/sbin dedans.