Configuration de sudo

Pause Café
#21

Ça ne m’interdit pas de répondre :slightly_smiling: surtout que j’ai donné des éléments construit et pas simplement fait du troll.
Je pense sincèrement que le seul vrai problème de su comme du sudo ce trouve entre la chaise et le clavier (contrairement à ce que tu dis plus haut) et les 2 demande de la rigueur pour ne pas faire n’importe quoi.

[mono]su[/mono] demande à faire des aller-retour fréquents et fastidieux entre le compte utilisateur et le compte privilégié.
[mono]sudo[/mono] demande à réfléchir un peu avant de le lancer.

@ricardo > Au début du sudoers (en principe il y a déjà d’autres lignes de Defaults)
Si si tu peux toujours t’en servir, c’est juste que l’authentification sur un terminal ne t’authentifiera pas dans l’autre.
Imagine que tu as 2 terminaux avec un timeout d’une minute. Si tu lance sudo dans le permier, puis que tu lance sudo dans le second, tu n’aura pas à taper une seconde fois ton mot de passe (sauf si tu active [mono]tty_tickets[/mono]).

#22

Salut,

Je rajoutes donc “targetpw” à mes “defaults” et avec timestamp=0 je vais continuer à utiliser sudo et kdesudo :slightly_smiling:

#23

Ça ne m’interdit pas de répondre :slightly_smiling: surtout que j’ai donné des éléments construit et pas simplement fait du troll.
Je pense sincèrement que le seul vrai problème de su comme du sudo ce trouve entre la chaise et le clavier (contrairement à ce que tu dis plus haut) et les 2 demande de la rigueur pour ne pas faire n’importe quoi.

[mono]su[/mono] demande à faire des aller-retour fréquents et fastidieux entre le compte utilisateur et le compte privilégié.
[mono]sudo[/mono] demande à réfléchir un peu avant de le lancer.

@ricardo > Au début du sudoers (en principe il y a déjà d’autres lignes de Defaults)
Si si tu peux toujours t’en servir, c’est juste que l’authentification sur un terminal ne t’authentifiera pas dans l’autre.
Imagine que tu as 2 terminaux avec un timeout d’une minute. Si tu lance sudo dans le permier, puis que tu lance sudo dans le second, tu n’aura pas à taper une seconde fois ton mot de passe (sauf si tu active [mono]tty_tickets[/mono]).[/quote]

Pas tout à fait, prenons mon exemple précis, j’ai sudo pour ce qui suit:

donc je ppeux arrêter lamachine, régler la brillance (ne sert plus à rien), mettre en veille ou en hibernation par script, installer des paquets, lancer plusieurs vpn, regarder powertop, manipuler les extensions de clefagreg sans passer en root. Comme je suis dans le groupe adm, je peux lire les logs. En clair je ne tape jamais mon mot de passe (même pour installer un paquet) sauf au login et je ne passe quasiment jamais root. Il suffit que les commandes évoquées dans le sudoers soient bordées ce qui est le cas.
Je ne me retrouve quasiment jamais dans la situation où même volontairement je pourrais casser la machine, et ceux par l’utilisation prévue de sudo à savoir confier à l’utilisateur averti francois (c’est moi) l’autorisation de quelques commandes importantes pour lui. Cependant même ivre, pressé ou épuisé ce crétin ne pourra pas bousiller involontairement la machine.

Voilà pour moi la bonne utilisation de sudo. J’ai minimisé les situations où j’ai les droits root en bordant les situations où j’ai besoin des droits root (même importants).

Habituer un utilisateur à faire une batterie de sudo ou de su -c ou de su (c’est pareil) banalise le passage en root. Un «=ALL» me parait donc une source potentielle d’ennuis.

Rq: La situation est différente sur un serveur géré par plusieurs personnes.

#24

[quote=“fran.b”]

Rq: La situation est différente sur un serveur géré par plusieurs personnes.[/quote]

Pourtant ton exemple est clairement ce que l’on fait quand les commerciaux arrive à nous vendre une plateforme en infogérance avec un accès SSH au client :083

(Hérésie quant tu nous tient - infogérance avec accès SSH au client :005 :005 :005 ).

Sudo est clairement un outil à savoir utilisé avec parcimonie, il peut être pratique comme destructeur et comme déjà abordé su comme sudo amène bien souvent à un problème d’interface chaise/clavier.

Je rappelle juste qu’il y a deux an une plateforme XEN chez moi à été foutue en l’air par un petit hacker de moins de deux an car une console sous su est resté ouverte avec un clavier branché :whistle:

#25

Ça demande un bon niveau d’administration. Tu dois avoir cerné tes besoins et mis en place les sécurité qui vont bien sur les scripts en question (au passage c’est quelque chose de plus simple à faire avec sudo, mais rien de très compliqué à faire via des droits).

Intéressant mais tu propose quoi alors ?
Ne pas permettre aux gens de faire l’administration de leur machine ?

#26

[quote=“ricardo”]Quelle différence entre :
placer un utilisateur dans le groupe sudo
placer un utilisateur comme ALL (ALL) ALL
aucune ou il y a une subtilité que j’ignore :question:[/quote]
Ça dépend de ta conf. Le fichier de conf de sudo chez Debian (stable) arrive avec la ligne :

Donc pas de différence.

#27

C’est donc bien ce que je pensais.
Merci.

#28

[quote=“MisterFreez”]Ça demande un bon niveau d’administration. Tu dois avoir cerné tes besoins et mis en place les sécurité qui vont bien sur les scripts en question (au passage c’est quelque chose de plus simple à faire avec sudo, mais rien de très compliqué à faire via des droits).

Intéressant mais tu propose quoi alors ?
Ne pas permettre aux gens de faire l’administration de leur machine ?[/quote]

Je l’ai dit et résumé, sur une machine de travail, les besoins administratifs sont limités. Même si tu fais un projet nécessitant des droits importants comme ClefAgreg, tu peux les résumer à un ou deux scripts ou tu te donnes les droits. Je suis root très rarement sur ma machine. On ne passe pas sa vie à administrer sa machine… Si on veut jouer avec ta machine et passer ton temps à changer de gestionnaire de fenêtres, de version de noyau, etc, dans ce cas de toute façon ça n’a pas d’importance, un rm -Rf / ne sera qu’une occasion de passer son temps.