[quote=“ggoodluck47”]Salut,
[quote]Et j’aimerais bien que quelqu’un me dise quelle est la différence fondamentale entre
Code:
sudo commande
et
su -c commande
[/quote]
Aucune pour toi, mais c’est parce que root t’a donné son MDP 
[/quote]
Mais pour que sudo soit utilisable par un utilisateur, il faut que cet utilisateur soit dans le groupe wheel ou ait son nom dans le sudoers, donc root lui a aussi donné ces privilèges, non ? Et il y a une option dans le fichier pour demander le mot de passe de root et pas celui de l’utilisateur. Donc j’ai du mal à comprendre pourquoi su -c est mieux que sudo.
Re,
Quand au copié/collé qu’ils soient en su ou sudo ces mêmes débutants feront la même chose. J’en veux pour preuve celui qui hier cherchait à lancer une session graphique root 
C’est pour cela que nous, les “anciens” devons leur donner de bonnes habitudes dés le début. Lorsqu’ils maitriseront un peu mieux leur système, libre à eux de dévergonder leur sudoers.
Et pour ça, ils n’auront pas besoin de debian-fr, depuis quelques temps les “bons conseils” pullulent sur les wikis.
!
[quote=“lol”]C’est fait…
J’en ai profité pour ajouter la commande suivante:
Qui revient finalement à un sudo non ? 
[/quote]
non !
Il est impératif de connaître le mdp root pour l’utiliser, alors que ce n’est pas le cas des “autorisés” à “sudo”.
Le seul avantage qu’a cette commande, c’est de ne pas réduire en temps la commande classique avec 'su -", si on veut la laisser libre de timeout “?”.
Si nombreuses commandes à effectuer sous root : "su -"
retour = toujours sous root
Si une seule commande à effectuer sous root : “su -c commande” ou "su -c ‘commande plusieurs mots’"
retour = en ‘user’ automatiquement, pas de problème d’oubli de retour-user.
Seulement si l’admin a donné à l’‘user’ TOUS les droits de “sudo” (et encore, il en reste certains pour lesquels il faut être vraiment “root”).
On répète, une fois de plus, en partant du principe que la machine est “multi-utilisateurs” :
Sudo est en principe, réservé à certains ‘users’ pour certaines commandes, JAMAIS pour TOUTES les commandes.
Éventuelement, l’admin peut s’octroyer TOUS les droits ‘sudo’, pour une question de mdp plus facile.
[quote=“kamui57”]Et il y a une option dans le fichier pour demander le mot de passe de root et pas celui de l’utilisateur. Donc j’ai du mal à comprendre pourquoi su -c est mieux que sudo.[/quote]Voir la réponse dans le message précédent :
que ce soit “su -” ou “su -c commande”, ces deux choses sont réservées à l’admin, point.
Tout ce qui vient d’être écrit, est valable pour une machine qui est ouverte à plusieurs utilisatuers.
Si tu es seul sur ta machine et que ton mdp ‘user’ soit en béton, tu peux t’octroyer tous les droits que tu veux. Par contre, si tu es relié au net, il est préférable de ne pas rester trop longtemps sous root, d’où l’avantage de “su -c commande”
[quote=“lol”]C’est fait…
J’en ai profité pour ajouter la commande suivante:
Qui revient finalement à un sudo non ? [/quote]
Pas du tout !
Si on considère, comme moi (et j’en connais d’autres) que l’user ayant des droits avec sudo doit avoir un pass en béton et que ‘root’ doit l’avoir en “béton armé”, la commande
su -c ‘commande à taper’
nécessite le pass "root’ donc béton armé
la commande ‘sudo’, elle, ne nécessite que le pass ‘user’ donc en 'béton simple’
De plus,
su -c commande (ou ‘commande en plusieurs mots’)
coupe la pérennité de root sitôt passée
alors que
sudo commande
si le timestamp est > 0, conserve la possibilité d’incursion malveillante.
Besoin explications :
machine 1 : quand je tape ‘su -’, je passe sous root et j’y demeure ad vitam eternam
serveur . : quand je tape ‘su -’, je passe sous root et je reviens sous ‘user’ au bout de 5 mn
/root/.profile : exactement les mêmes sur les deux machines
sudoers … : exactement les mêmes sur les deux machines
default env_reset = idem sur les deux machines, sans aucune autre donnée.
Pas de timestamp indiqué.
J’ai “arrangé” avec le fameux export TMOUT=XXX - readonly TMOUT
Mais je reste en suspend sur l’endroit où se gère ce “env_reset” ?
Je viens de relire tout ce fil et je n’ai vu nulle part un exemple de commande sudo pour un acte unique : c’est une lacune.
Je vais voir sur le wiki si cette lacune est comblée.
EDIT :
Non, rien de plus, sinon les alias mais ce n’est pas tout à fait comparable.
Alors, comme je ne veux pas écrire de conneries, qui peut envoyer la ligne exacte et complète à écrire dans sudoers pour que l’utilisateur
user
puisse envoyer avec sudo la commande
rsync -av --del --backup --backup-dir="$1" --exclude-from="$2" “$3” "$4"
ET RIEN QUE CELLE-LÀ
Pour accorder toutes les commandes avec ‘rsync’, c’est facile mais une seule, je suppose qu’il doit y avoir des guillemets ou des accolades à placer, non ?
[quote=“ricardo”]Je viens de relire tout ce fil et je n’ai vu nulle part un exemple de commande sudo pour un acte unique : c’est une lacune.
Je vais voir sur le wiki si cette lacune est comblée.[/quote]
Defaults:ALL timeout_timestamp=0
J’ai complété ma demande, merci de reprendre plus haut.
[quote=“ricardo”][quote=“lol”]C’est fait…
J’en ai profité pour ajouter la commande suivante:
su -c commandeQui revient finalement à un sudo non ? [/quote]
Pas du tout !
Si on considère, comme moi (et j’en connais d’autres) que l’user ayant des droits avec sudo doit avoir un pass en béton et que ‘root’ doit l’avoir en “béton armé”, la commande
su -c ‘commande à taper’
nécessite le pass "root’ donc béton armé
la commande ‘sudo’, elle, ne nécessite que le pass ‘user’ donc en ‘béton simple’
De plus,
su -c commande (ou ‘commande en plusieurs mots’)
coupe la pérennité de root sitôt passée
alors que
sudo commande
si le timestamp est > 0, conserve la possibilité d’incursion malveillante.[/quote]
Bon je vois tous de même une différence notable avec sudo et su -c c’est que l’utilisateur de sudo c’est l’utilisateur ( et il a les droits que l’on lui a octroyer par le fichier sudoers ) et dans le deuxième cas c’est root mais l’une comme l’autre sitôt la commande utilisé ( et si on n’a paramétrer de façon sécurisé sudo ) il n’est pas possible de lancer une commande exigeant des droits supérieur à ce que l’utilisateur peut lancer.
Donc pour moi la différence reste subtile pour une utilisation réfléchie il n’y a aucun souci 
Après je préfère tout de même utilisais su -c pour la bonne et simple raison c’est que je suis l’administrateur de mes machines et je peut ainsi suivre mes commandes ( depuis root ) dans historiques uniques, mais pour ce qui est des comptes invités et autres personnes avec des droits restreints il reste l’utilisation de sudo avec la configuration associer 
.
Donc plutôt que de lancer une authentification root pour une simple commande et de se déconnecter ensuite pour plus de sureté je trouve plus simple de faire ainsi, après pour le cas en question la personne rencontre un bogue référencé de l’utilisation de sudo et d’un répertoire personnel chiffrée ( ce qui étais un conseil d’utilisation temporaire ).
Donc pour moi su -c reste le pendant de sudo pour un administrateur de machine mais reste à proscrire pour un utilisateur lambda.
+1
Comme ma demande a été enterrée, je la réitère :
[quote]Alors, comme je ne veux pas écrire de conneries, qui peut envoyer la ligne exacte et complète à écrire dans sudoers pour que l’utilisateur
user
puisse envoyer avec sudo la commande
rsync -av --del --backup --backup-dir="$1" --exclude-from="$2" “$3” "$4"
ET RIEN QUE CELLE-LÀ
Pour accorder toutes les commandes avec ‘rsync’, c’est facile mais une seule, je suppose qu’il doit y avoir des guillemets ou des accolades à placer, non ?
[/quote]
Re,
Defaults:ALL tty_tickets, timestamp_timeout=0
préconisée par Fran
[quote=“ricardo”]CAlors, comme je ne veux pas écrire de conneries, qui peut envoyer la ligne exacte et complète à écrire dans sudoers pour que l’utilisateur
user
puisse envoyer avec sudo la commande
rsync -av --del --backup --backup-dir="$1" --exclude-from="$2" “$3” "$4"
ET RIEN QUE CELLE-LÀ
Pour accorder toutes les commandes avec ‘rsync’, c’est facile mais une seule, je suppose qu’il doit y avoir des guillemets ou des accolades à placer, non ?[/quote]
Si tu crées un script contenant cette commande (droits rwxr-xr-x, propriétaire root:root pour empêcher qu’un utilisateur lambda le modifie) et que tu autorises le script en question dans les sudoers (avec n’importe quels arguments), ça revient au même non ?
Cerise sur le gâteau, dans le script tu peux même vérifier que le contenu des arguments soit correct (liste de chemins spécifique, …) ce qui est encore plus sécurisé que ce que tu souhaites faire. 
Et en plus ça fera moins à taper quand tu appelleras ta commande via sudo… 
[quote=“syam”][quote=“ricardo”]CAlors, comme je ne veux pas écrire de conneries, qui peut envoyer la ligne exacte et complète à écrire dans sudoers pour que l’utilisateur
user
puisse envoyer avec sudo la commande
rsync -av --del --backup --backup-dir="$1" --exclude-from="$2" “$3” "$4"
ET RIEN QUE CELLE-LÀ
Pour accorder toutes les commandes avec ‘rsync’, c’est facile mais une seule, je suppose qu’il doit y avoir des guillemets ou des accolades à placer, non ?[/quote]
Si tu crées un script contenant cette commande (droits rwxr-xr-x, propriétaire root:root pour empêcher qu’un utilisateur lambda le modifie) et que tu autorises le script en question dans les sudoers (avec n’importe quels arguments), ça revient au même non ?
Cerise sur le gâteau, dans le script tu peux même vérifier que le contenu des arguments soit correct (liste de chemins spécifique, …) ce qui est encore plus sécurisé que ce que tu souhaites faire.
Et en plus ça fera moins à taper quand tu appelleras ta commande via sudo… [/quote]
+1 J’ai un peu regardé, et les commandes complexes n’ont pas l’air d’être appréciées (man sudoers)
[quote]sudo: >>> /etc/sudoers: syntax error near line 17 <<<[/quote]
[quote=“syam”][quote=“ricardo”]CAlors, comme je ne veux pas écrire de conneries, qui peut envoyer la ligne exacte et complète à écrire dans sudoers pour que l’utilisateur
user
puisse envoyer avec sudo la commande
rsync -av --del --backup --backup-dir="$1" --exclude-from="$2" “$3” "$4"
ET RIEN QUE CELLE-LÀ
Pour accorder toutes les commandes avec ‘rsync’, c’est facile mais une seule, je suppose qu’il doit y avoir des guillemets ou des accolades à placer, non ?[/quote]
Si tu crées un script contenant cette commande (droits rwxr-xr-x, propriétaire root:root pour empêcher qu’un utilisateur lambda le modifie) et que tu autorises le script en question dans les sudoers (avec n’importe quels arguments), ça revient au même non ?
Cerise sur le gâteau, dans le script tu peux même vérifier que le contenu des arguments soit correct (liste de chemins spécifique, …) ce qui est encore plus sécurisé que ce que tu souhaites faire.
Et en plus ça fera moins à taper quand tu appelleras ta commande via sudo… [/quote]
Il ne s’agissait que d’un exemple que j’ai pris dans une commande volontairement longue.
En fait, je voulais savoir s’il était possible de n’autoriser à l’user “machin” qu’une seule entrée.
Exemple :
machin PC-truc=rsync/seulement/dans/le/dossier/bidule
Ce qui, dans mon esprit, n’autoriserait pas machin à se servir de rsync pour autre chose.
J’avoue que je ne sais pas bien expliquer sur ce coup.
[quote=“ricardo”]
Il ne s’agissait que d’un exemple que j’ai pris dans une commande volontairement longue.
En fait, je voulais savoir s’il était possible de n’autoriser à l’user “machin” qu’une seule entrée.
Exemple :
machin PC-truc=rsync/seulement/dans/le/dossier/bidule
Ce qui, dans mon esprit, n’autoriserait pas machin à se servir de rsync pour autre chose.
J’avoue que je ne sais pas bien expliquer sur ce coup.[/quote]
Oui tu doit pouvoir restreindre le “pouvoir” de sudo à certaines fonctionnalités de certaines commandes mais dès que ça se complique trop je préfère préparé des alias ou des scripts que je pilote par le biais de sudo.
Explique-moi, dans le cas que je soumets plus haut :
“machin” sur la machine "PC-truc"
ne doit pouvoir utiliser sudo QUE pour la commande
rsync /avec/des/options/et/un/chemin/bien/précis
et pas pour une autre commande, même avec 'rsync’
Comment écris-tu tout ça ?