Information sudo / gksu

Support Debian
#1

Bonjour,

Je voudrais savoir pq lorsque j’utilise sudo le terminal me renvoie [sudo] password for debshoob debshoob is not in the sudoer files. The incident will be reported

Alors qu’en utilsant gksu ça marche bien.

C’était pour [quote]sudo gedit /etc/samba/smb.conf[/quote] qui n’ouvrait pas le fichier alors que [quote]gksu gedit /etc/samba/smb.conf[/quote] l’ouvrait.

En outre, j’ai voulu faire debshoob@debianshoob:~$ gksu sudo adduser debshoob admin adduser : Le groupe « admin » n'existe pas. Donc, soit, sans créer le groupe admin comment je procède pour que debshoob soit sudoer
ou alors est-ce qu’il faut que je crée un groupe admin que je pensais qu’il ne fallait pas faire ?

Merci à vous

#2

re, on te dit que ton user n’est pas dans le fichiers sudoers
edite /etc/sudoers et ajoute toi a la liste des users
a+

#3

commande visudo en root

#4

[quote=“jeanbi”]re, on te dit que ton user n’est pas dans le fichiers sudoers
edite /etc/sudoers et ajoute toi a la liste des users
a+[/quote]

Tu ouvres le fichier (en tant que root) avec la commande :

visudo

tu verras la 1ère ligne (en rouge ici)
tu rajoutes en dessous le seconde (en vert ici)
“ricardo” étant, bien sûr, à modifier :smt003

root ALL=(ALL) ALL
ricardo ALL=(ALL) ALL

#5

Merci à vous pour la célérité. :smiley:

Je vous dis dès que c’est fait. :smt006

#6

re, me plait pas beaucoup votre fichier
un comme ceci

[quote]#

This file MUST be �ites with the ‘visudo’ command as root.

See the sudoers man page for the details on how to write a sudoers file.

Host alias specification

User alias specification

User_Alias STAFF = debshoob

Cmnd alias specification

Cmnd_Alias STOPPC = /sbin/mount, /sbin/halt, /sbin/reboot, !/sbin/shutdown -*,/sbin/shutdown -r, /sbin/shutdown -h
ici definition des droits

Defaults specification

User privilege specification

root ALL=(ALL) ALL
#Root peut tout

Uncomment to allow people in group wheel to run all commands

%wheel ALL=(ALL) ALL

STAFF ALL = (ALL) STOPPC
ici les gens du groupe STAFF peuvent effectuer les commandes editer dans STOPPC

Same thing without a password

%wheel

ALL=(ALL) NOPASSWD: ALL
Ici suppression de la demande du mot de passe
qui serait celui de l’utilisateur et non du Root [/quote]
par exemple mais mettre l’user au niveau du root !!!
a+

#7

[quote=“ricardo”]root ALL=(ALL) ALL
ricardo ALL=(ALL) ALL[/quote]
Les mêmes droits pour l’utilisateur que pour le root ?!
Et pourquoi pas une *buntu tant qu’on y est ?!

Plus sérieusement, il y a tout intérêt à être TRÈS prudent lorsqu’on qu’on joue avec le sudoers pour attribuer des droits à un utilisateur !

Personnellement, étant le seul utilisateur de ma machine, l’utilisateur n’a que les droits “normaux”, et plutôt que ‘sudo commande’, j’utilise ‘su -c commande’ qui demande le mot de passe root et n’accorde aucun privilège à l’utilisateur…
Plus sécurisé de mon point de vue, et permet de clairement différencier les activités de l’utilisateur et celles du root.

#8

Bien sûr, après on peut affiner mais là ce n’est que pour montrer à notre ami, quoi faire pour avoir des droits avec 'sudo’
Ensuite, il doit lire le man sudoers et faire selon ses choix.

#9

[quote]Les mêmes droits pour l’utilisateur que pour le root ?!
Et pourquoi pas une *buntu tant qu’on y est ?![/quote]

il suffit de ne pas le mettre, s’en seras mieux securisée mais fini les sudo … ^^

#10

Faudrait ptet aussi arrêter d’être parano, hein ! :mrgreen:

#11

de mon coter le su -c ne marche pas a tout les coups , par contre un kdesu oui ^^

[LOOOOOOL] , ce n’est pas parceque l’on est parano qu’ils n’en n’ont pas apres nous …[/LOOOOOL]

#12

re, pas de parrano,mais si c’est pour se retrouver avec une distribution protéger comme windows !!!
donc que l’on se serve de sudo ok mais dans un cadre defini pas à la façon ubuntu surtout.
a+

#13

…tout a fait !!! :wink:

(malgres que je ne pense pas que cela puisse etre…)

#14

Quoi quoi quoi ?
Développe ta pensée…
Je ne suis encore jamais tombé sur une situation où ‘su -c’ m’a lâché !
Tu as un exemple de commande où ça ne marche pas ?

#15

bien sur ^^

$ su -c mc
Mot de passe :
su : Échec d'authentification

$ su -c iceape
Mot de passe :
su : Échec d'authentification

…°°… ?

#16

@ Grhim : Je viens de tester tes deux commandes, avec succès dans les deux cas !
Le message d’erreur que tu reçoit semble indiquer un mauvais mot de passe…
Tu utilises bien ton mot de passe root ?

#17

salut vv222 ^^

rhaaalala , en faite non je le faisais a la sudo …grrrr mais en tapant avec le mot de pass root afin d’ouvrir synaptic par exemple, j’ai le fatidigue :

$ su -c synaptic
Mot de passe :
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

par contre la ou cela devient interressant c’est que si je lui demande d’ouvrir mc, là ca fonctionne …

$ su -c mc
Mot de passe :

et mc s’ouvre…

c’est pour cela que je disais que c’etait aleatoire suivant ce que je lui demande
marche pas a tout les coups

hummm je pige pas trop :confused:

#18

Normal, X bloque les applications graphiques lancées par root.

Pour lancer synaptic ou tout autre programme graphique en root, tu peux utiliser gksu :

On doit aussi pouvoir faire en sorte de pouvoir utiliser su, mais je n’en parlerai pas, de peur de dire des conneries…

#19

[quote]Normal, X bloque les applications graphiques lancées par root.
[/quote]

…c’est bien ce que j’ai penser , c’est pour cela que j’utilise kdesu a la place pour ceux en graphique :blush: :smt002

mal reveiller aujurdhui :blush:

#20

[quote=“vv222”]Personnellement, étant le seul utilisateur de ma machine, l’utilisateur n’a que les droits “normaux”, et plutôt que ‘sudo commande’, j’utilise ‘su -c commande’ qui demande le mot de passe root et n’accorde aucun privilège à l’utilisateur…
Plus sécurisé de mon point de vue, et permet de clairement différencier les activités de l’utilisateur et celles du root.[/quote]
C’est parfait ce petit “-c” merci pour le truc (c’est pas vraiment clair dans ‘man su’…) :wink: