Demande de confirmation avec sudo

Support Debian
#1

Salut :wink:

J’ai récemment adopté sudo pour passer mes commandes d’administration à la place du très décrié su.

Or j’utilise le shell zsh et dans mes fichiers de config zshrc (pour root et l’utilisateur lambda) j’ai qq alias de ce genre :

alias rm='rm --interactive'
...

bien pratiques qd on a les doigts + rapides que les neurones…

Malheureusement, qd je fais un sudo rm …
… est détruit sans confirmation. Jusqu’à maintenant, j’ai réussi à éviter les catastrophes mais ça ne va pas durer.

Y-a-t-il un moyen de passer ces alias dans /etc/sudoers ? J’ai cherché dans man sudoers mais je n’ai trouvé que la directive ‘Cmnd_Alias’ qui ne semble pas correspondre à ce que je cherche.

Merci si vous savez :wink:

#2

rm est ptet protégé ?
et si tu changes ton alias ?
pour essai,
alias rmbis=‘rm --interactive’

#3

Remets toi à su! Personnellement, c’est pour éviter ce genre de trucs que je n’utilise pas sudo. sudo est réservé à des scripts où à des commandfes très précises pour des personnes très précises, pour moi ça n’est pas une alternative (meilleure? moins bonne?) à su.

#4

[quote=“ricardo”]rm est ptet protégé ?
et si tu changes ton alias ?
pour essai,
alias rmbis=‘rm --interactive’[/quote]

La syntaxe alias rm=‘rm --interactive’ fonctionne très bien pour root et lambda mais pas pour lambda utilisant sudo. C’est ce que je voulais dire :wink:

#5

Disons que ça oblige à taper son mot de passe (utilisateur et non root) à intervalle régulier (le délai peut être choisi d’ailleurs) et donc ça sécurise un peu par rapport à su.

Tu n’es pas obligé de déclarer chaque exécutable dans sudoers, tu peux créer un groupe auquel tu appartiens qui a les droits d’administration. C’est la config par défaut chez Ubuntu.

#6

En gros, à la longue ça revient à créer des utilisateurs qui, moyennant le fait de taper de temps à autre leur mot de passe, passe des commandes systèmes avec sudo devant, le tout en 3 secondes. Autant se donner directement les droits root, ça revient à cela. Je pense d’ailleurs que si il y a des virus sous linux, ceux ci utiliseront le «sudo». Combien ont supprimé cette demande de mot de passe? Combien ont par confort étendu leur droit à toutes les commandes? Bref, on répète les erreurs de Windows pour un gain de confort.

#7

Oui, c’est aussi pratique si plusieurs personnes fréquente l’ordi.
on peut dédier qq possibilités non cruciales seulement à un utilisateur, qui devient ainsi un mini patron, en restreignant la portée de sudo.
Le “patron” restant celui qui a le pass root.

#8

[quote=“fran.b”]Combien ont supprimé cette demande de mot de passe?[/quote]mouaip ben pas grand monde j’espère …
Comme tu le disais, on configure sudo pour des commandes trés précises, avec une directive NOPASSWD pour des tâches automatisées ne demandant pas l’intervention de l’utilisateur et trés limitées et bien spécifiées … en ça, sudo reste un bon outil je pense.

cet alias ne me parait pas correct, j’aurais plutôt fait :

et dans /etc/sudoers :

puis ce qui va avec dans la section user privilege specification.
A tester …
Normalement, un alias prend la main sur la commande originelle, cad rm sera interprété comme l’alias, et plus comme /bin/rm. Mais faut être sur que ton alias soit connu du shell au moment où tu l’invoques aussi …
Ceci dit, je vois pas pourquoi faire un alias d’un truc qui se configure automatiquement … --interactive n’est-il pas une option présente par défaut ? chez moi oui où je me souviens plus ce que j’ai fait pour que ça soit automatique alors …

EDIT: parce que donner acces au bin/rm à un user ça peut être dangereux; ça me gênerait qu’un user puisse supprimer des fichiers root, et c’est ce que tu essayes de faire Bluenote …

#9

[quote=“usinagaz”]

cet alias ne me parait pas correct, j’aurais plutôt fait :

Oui mais je ne veux pas que rm devienne sudo rm, si tu vois ce que je veux dire…

Ah non, chez moi, sans cet alias, je n’ai pas de confirmation.

[quote=“usinagaz”]
EDIT: parce que donner acces au bin/rm à un user ça peut être dangereux; ça me gênerait qu’un user puisse supprimer des fichiers root, et c’est ce que tu essayes de faire Bluenote …[/quote]

L’utilisateur c’est moi et root c’est un autre moi, donc :wink: Pour qu’un autre utilisateur accède au groupe d’administration, il lui faut le mp root.
Et encore une fois, c’est la config Ubuntu par défaut, je n’ai rien inventé. Je pense que cette modif a au moins pour objectif de sécuriser un peu plus le système.

Pour le reste (sudoers), je vais tester ce que tu me dis, merci :wink:

#10

Ok, je passe vite fait, je vais y “réfléchir”, non mais à la volée, je voudrais dire deux choses :

  • tu trouveras en recherchant ici “sudo” “mount” surement une discussion avec Ricardo où on parlait de ce genre d’alias …
  • [quote=“Bluenote”]L’utilisateur c’est moi et root c’est un autre moi, donc :wink: Pour qu’un autre utilisateur accède au groupe d’administration, il lui faut le mp root.[/quote]Ah ben non, enfin oui, moi aussi root = moi, mais …
    imagines que tu aies configurer la commande avec NOPASSWD, et qu’un gars (venant du net) arrive par on ne sait quelle faille à se loguer sous ton user (mettons que ton user n’aie pas un mot de passe de l’accabit de root’s), tu imagines les dégâts ?
#11

Au niveau de la sécurité pour sudo, il ya ptet une autre possibilité qui éviterait le sans_pass que je ne pratique pas :
Faire un pass court et pratique à taper et le changer fréquemment. les champions du script doivent pouvoir automatiser ça.
On doit aussi pouvoir jouer sur le tps d’ouverture : si on travaille beaucoup avec la console, tps assez long et si on est plutôt ds une journée surf, tps court, genre parano.

#12

je vois que tu as creusé ton sujet … :smiley:
je sais pas … je sais pas … 8)

#13

Je vois que le sujet vous passionne :mrgreen:

Personnellement, je n’utilise le nopasswd que pour des commandes précises et pas trop sensibles qui se font via des outils graphiques (shutdown, ifdown) que ‘MOI’ utilise. Et le mot de passe de ‘MOI’ est quasiment aussi dur que celui de root.
J’utilise tjs une temporisation courte et ça me convient. En utiliser une longue revient presque à rester logguer en root…

Cliquer sur un truc qui me coupe le réseau est plus rapide que taper ifdown --force eth0 en root. Le but étant de réagir lorsque mon serveur web est ouvert et que mes logs m’affichent : “GROS MECHANT LANCE UNE ATTAQUE” :wink:

#14

Pour info, j’ai essayé l’idée usinagazienne :

/etc/sudoers :

Cmd_Alias RM=/bin/rm --interactive

et sudo m’écrase encore mes fichiers sans s’émouvoir.
Bref, ce sera à moi de faire attention :wink:

#15

hello,

“rm -i”

#16

le mieux à faire c’est un petitsu - motdepasse cd / rm -rf * :laughing: :laughing: :laughing: :laughing:

Ps: c’est a faire a vos risques et péril

#17

[quote=“Bluenote”]Pour info, j’ai essayé l’idée usinagazienne :

/etc/sudoers :
Cmd_Alias RM=/bin/rm --interactive

et sudo m’écrase encore mes fichiers sans s’émouvoir.
Bref, ce sera à moi de faire attention :wink:[/quote]
C’est un peu plus compliqué que ça en fait … disons que chez moi, par défaut, rm demande confirmation pour tout écrasement de fichier pour lequel l’user n’a pas les droits en écriture alors que ce fichier est dans un repertoire appartenant à l’user, nuance … et aprés confirmation, rm s’exécute …
Exemple :

[code]$ cd ~
$ su

mkdir testdir

nano testdir/testrm

su user

$ rm testrm
rm: détruire un fichier protégé en écriture fichier régulier testrm'? o rm: ne peut enlevertestrm’: Permission non accordée
$ su

chown user ./

su user

$ rm testrm
rm: détruire un fichier protégé en écriture fichier régulier `testrm’? o
[/code]le fichier est détruit ! alors qu’il appartient à root, je suis perplexe.
A noter que si je remet root propriétaire du répertoire, que je chown user le fichier testrm, là, j’ai même pas la demande de confirmation, c’est direct Permission non accordée. (D’où la grande importance des droits des repertoires par rapport au fichier : l’user ne peut pas détruire un fichier qui lui appartient dans un repertoire qui ne lui appartient pas …).
Est-ce que tes soucis ne viendrait pas des mask que tu appliques à tes repertoires et fichiers Bluenote ?
Alors bon moi j’ai fait le processus inverse de toi, vu que chez moi, c’est plutôt le forçage qui ne va pas de soi, donc j’ai fait ceci, essayes d’adapter.
Situtation : je force par un alias l’écrasement de testrm qui appartient à l’user dans un repertoire appartenant à root dans l’home de l’user : testdir.

[code]root@debian:/home/user/testdir# ls -al
total 16
drwxr-xr-x 2 root root 4096 2006-11-27 04:46 .
drwxrwxr-x 96 user user 8192 2006-11-27 04:36 …
-rw-r–r-- 1 user root 5 2006-11-27 04:34 testrm

nano /etc/sudoers

–> ajout : Cmnd_Alias RM=/bin/rm -f *
–> ajout : NOPASSWD:RM,

/etc/init.d/sudo restart

nano /home/user/.bash_aliases

–> ajout : alias rm='sudo rm -f’
su user
$ source /home/jcode/.bash_aliases ou plutôt peut-être .bashrc
$ rm testrm[/code]
Et je suis sur que c’est bien l’alias qui a été exécuté … l’astuce est de mettre une * à RM=/bin/rm -f *. Il semble que ça n’est pas interprété comme ‘tous fichiers du répertoire courant’, mais comme ‘tout fichier passé en paramètre’ :wink: j’ai testé.

#18

[quote=“Ashgenesis”]le mieux à faire c’est un petitsu - motdepasse cd / rm -rf * :laughing: :laughing: :laughing: :laughing:
Ps: c’est a faire a vos risques et péril[/quote]
Tiens ça me fait penser qu’un alias du genre alias rm=‘rm --preserve-root’ # ne pas opérer récursivement sur « / » serait pas inutile … pour root lui-même (cad ‘moi’ et mes boulettes) :unamused:

#19

Question subsidiaire :

[quote=“man rm”]Notez que si vous utilisez « rm » pour détruire un fichier, il est
habituellement possible de récupérer le contenu de ce fichier. Si vous
voulez réellement que son contenu soit irrécupérable, utilisez plutôt
shred.
[/quote]Ah bon ?! et où et comment il est récupérables ?
Même sur un systeme de fichier ext3 ?? (je fais allusion à l’absence de soft permettant un undelete ou récuperation de fichier détruit pour ext3, contrairement à ext2).

#20

Stonfi :

Hello,

Oui c’est vrai c’est + court. Mais comme avec l’alias je n’avais pas besoin de le taper :wink: