[Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

Coeur Noir · Le 12/10/2022, à 18:12

Cela ne sera pas du 750 mais du 751......

Explique moi pourquoi, quel est l'intérêt ? À quoi ça sert un dossier ou fichier avec seulement un droit d'exécution pour les autres ?
Je ne vois aucune raison valable à ce choix mais je veux bien être convaincu du contraire avec un cas concret, un exemple parlant.

Des noms de compte à une seule lettre ( notamment la lettre c ) ça peut poser des tas de problème, utilise trois lettres au minimum.

Mais bon ça part déjà mal : si pour cet exercice « je » te propose des noms qui ont un sens « humain » c'est aussi pour te faciliter la tâche.
Et la mienne, si tu veux que j'arrive à te suivre vu ta tendance à partir tous azimuts.
Tu vois comment t'es tu dis:

Aussitôt que cela sera fini
Je vais créer un adjoint qui aura les mêmes pouvoirs que le chef

et résultat, tu es loin d'avoir fini que tu as déjà créé le suppléant.

Ensuite à partir du moment où tu utilises un OS, quel qu'il soit, c'est à toi utilisateur d'intégrer un minimum le fonctionnement interne, fondamental de ce système.
Si t'achètes une voiture qui fonctionne au super, tu vas pas y mettre un autre carburant dans le réservoir ?
Si t'as une scie sauteuse dans les mains, c'est pas pour t'en servir de brosse à cheveux ?
Ben là t'as un Linux dans les mains. Pas un Mac, pas un Windows ou autres. Tu dois donc composer avec ce que te propose Linux.

Dernière modification par Coeur Noir (Le 12/10/2022, à 18:24)

Coeur Noir · Le 12/10/2022, à 22:13

geole a écrit :

Cela fonctionne comme prévu. Qu ai-je pu faire pour que l autre contexte ne fonctionne pas?

Des bêtises

Dans ta dernière tentative ( #25 ) :
⋅ tu es partie d'une installation 22.04 propre, avec des $HOME en 750 appartenant respectivement à leurs $USER:$USER ;
⋅ tu n'as pas commis de chmod -R 771
…là c'est tout ce qu'on peut voir, je ne prétends pas que c'est l'explication.

Quelles sont les autres différences avec les contextes précédents ?
⋅ on ne sait rien de tes contextes précédents, nous, ici, de l'autre côté du web…
⋅ y'a plein de questions auxquelles t'as pas répondu ( la « nature » du dossier nommé SDD15 continue de m'intriguer )

Tu veux toujours pas nous dire d'où tu sors cette idée de chmod 771 ?
Un élément qui n'aurait que l'exécution ( sans lecture ) chez moi ressemble à

je ne vois pas à qui / à quoi il pourrait servir…

Bon j'attends comment tu fais pour obtenir :
⋅ soldat ne voit rien de adjoint et chef ;
⋅ adjoint peut écrire chez soldat ;
⋅ adjoint peut lire certains dossiers de chef, mais pas tous ;
⋅ chef voit et écrit chez tout le monde ;
⋅ adjoint peut écrire dans un dossier de chef ;
⋅ chef, adjoint et soldat peuvent écrire dans un dossier qui se trouve en dehors de leurs $HOME ;
⋅ et bien sûr les autres n'ont aucun droit dans aucun de ces $HOME.

Merci de changer le titre de cette discussion : les groupes vont bien, ton problème c'est que tu ne sais pas encore comment ça marche.

Dernière modification par Coeur Noir (Le 12/10/2022, à 22:17)

geole · Le 12/10/2022, à 22:34

Des bétises qui disparaissent en rebootant..........
Nota. je n'utilise pas le mode graphique.....
SDD15 est un dossier vide qui me sert de temps en temps comme point de montage de la partition sdd15

Dernière modification par geole (Le 12/10/2022, à 22:44)

Tawal · Le 12/10/2022, à 23:04

Hello,

Je reprends la lecture et je m'arrête sur le #7.
@Coeur Noir :

[ edit ] Et si tout le chemin jusqu'à ce dossier est lisible~traversable par les membres du groupe.

Je dirais juste lisible :

$ mkdir Test
$ ls -ld /home/tawal/Term/Test
drwxr-xr-x 2 tawal tawal 4,0K 12 oct.  23:48 /home/tawal/Term/Test/
$ chmod o-x Test/
$ ls -ld /home/tawal/Term/Test
drwxr-xr-- 2 tawal tawal 4,0K 12 oct.  23:48 /home/tawal/Term/Test/
$ su - pure
Mot de passe :
$ ls -l /home/tawal/Term/Test/
total 0
$ exit
$ chmod o-r+x Test/
$ ls -ld /home/tawal/Term/Test
drwxr-x--x 2 tawal tawal 4096 12 oct.  23:48 /home/tawal/Term/Test
$ su - pure
$ ls -l /home/tawal/Term/Test/
ls: impossible d'ouvrir le répertoire '/home/tawal/Term/Test/': Permission non accordée
$ exit
$ rmdir Test

Edit:
Quoique il faut les 2 :
Sans droit exécutable du dossier Test ayant un fichier texte banal dedans, mon utilisateur pure ne peut pas voir ce fichier :

$ ls -l /home/tawal/Term/Test
drwxr-xr-- 2 tawal tawal 4,0K 12 oct.  23:48 Test/
$ echo t > Test/t
$ su - pure
$ ls -l /home/tawal/Term/Test
ls: impossible d'accéder à '/home/tawal/Term/Test/t': Permission non accordée
total 0
-????????? ? ? ? ?              ? t
$ cat /home/tawal/Term/Test/t
cat: /home/tawal/Term/Test/t: Permission non accordée
$exit
$

Dernière modification par Tawal (Le 12/10/2022, à 23:19)

Coeur Noir · Le 13/10/2022, à 00:17

Tawal a écrit :

Je dirais juste lisible

Oui, depuis un terminal.
Pas depuis un explorateur de fichier « graphique » donc à évaluer, adapter selon le contexte « humain » d'utilisation finale.

Geole a écrit :

SDD15 est un dossier vide qui me sert de temps en temps comme point de montage de la partition sdd15

…faut vraiment t'arracher les vers du nez
Et donc ce dossier point de montage il a quels droits ?
Les options de ce montage ont-elles un risque de bloquer un utilisateur plutôt qu'un autre ?
→ À vérifier.
ET
les données DANS cette partition elles portent quels droits ?
→ disons qu'un point de montage est un dossier aux droits plutôt ouverts rwxr-xr-x mais les données dedans peuvent très bien être plus restrictives rwx------ ou appartenir à d'autres utilisateurs et groupes.

Des bétises qui disparaissent en rebootant..........

Non pas en rebootant.
Des bêtises complètement hypothétiques que tu n'aurais pas faites durant tes derniers essais, sur cette nouvelle installation de 22.04 que tu as laissée « comme neuve ».
J'écris bêtises mais c'est sans jugement, hein, car à part ce que j'ai évoqué au #27, le reste des différences entre les contextes il n'y a que toi qui pourrais le savoir,
à condition d'être « rigoureux » et « simple » dans les méthodes de test, pour pouvoir les reproduire, comparer et reporter facilement.

Nota. je n'utilise pas le mode graphique...

Ah bon ? Ça aussi il faut que les aidants potentiels le devinent ?
Oui là il y a un reproche : depuis le temps que tu fréquentes le forum, tu sais bien que quand il s'agit d'exposer une problématique, il faut
⋅ donner des infos sur le contexte,
⋅ rester dans ce contexte le temps du diagnostic,
⋅ et possiblement jusqu'à la résolution du problème.

Maintenant que tu es dans une situation « attendue » profites-en pour faire divers essais, en te donnant chaque fois un seul objectif :
je veux que tel et tel utilisateurs puissent faire telle chose à tel endroit,
je veux que tous les membres d'un groupe puisse lire-écrire-modifier-supprimer dans tel dossier, accessible à ce groupe seulement,
je ne veux pas que l'utilisateur B efface des affaires de A dans son $HOME mais je veux bien quand même que B puisse écrire dans le $HOME de A,
etc, etc, invente-toi des situations qui mettront à l'épreuve ta gestion des droits / propriétaires / utilisateurs / groupes.

Quand tu auras trouvé les mécanismes qui te conviennent alors tu pourras appliquer grandeur nature à un système déjà plein de données existantes… sachant que là, il faudra traiter ces données ( qui portent déjà des droits plus anciens, plus forcément raccords avec la nouvelle organisation que tu veux mettre en place. )
Attention au distinguo entre droits des fichiers et des dossiers.

Merci de changer le titre de cette discussion : tes groupes ne se comportent pas anormalement.
« Contexte multi-utilisateurs : quels droits sur et dans les $HOME ? » serait sans doute plus informatif, pour tout le monde.

geole · Le 13/10/2022, à 14:43

Bonjour coeur noir. Je vais répondre succinctement à tes questions. Mais il est inutile que tu continues d'intervenir dans cette discussion car tu t'égares.
.

Coeur Noir a écrit :

Geole a écrit :
SDD15 est un dossier vide qui me sert de temps en temps comme point de montage de la partition sdd15
…faut vraiment t'arracher les vers du nez
Et donc ce dossier point de montage il a quels droits ?

Cela a été montré à de multiples endroits, dont notamment avec la commande namei. Relis la discussion.

Coeur Noir a écrit :

Les options de ce montage ont-elles un risque de bloquer un utilisateur plutôt qu'un autre ?
→ À vérifier.
ET
les données DANS cette partition elles portent quels droits ?
→ disons qu'un point de montage est un dossier aux droits plutôt ouverts rwxr-xr-x mais les données dedans peuvent très bien être plus restrictives rwx------ ou appartenir à d'autres utilisateurs et groupes.

Le problème de cette discussion n'est un montage de partition. C'est totalement hors sujet.

Coeur Noir a écrit :

Des bêtises qui disparaissent en rebootant..........
Non pas en rebootant.
Des bêtises complètement hypothétiques que tu n'aurais pas faites durant tes derniers essais, sur cette nouvelle installation de 22.04 que tu as laissée « comme neuve ».
J'écris bêtises mais c'est sans jugement, hein, car à part ce que j'ai évoqué au #27, le reste des différences entre les contextes il n'y a que toi qui pourrait le savoir,
à condition d'être « rigoureux » et « simple » dans les méthodes de test, pour pouvoir les reproduire, comparer et reporter facilement.

Dans cette installation toute neuve, je connais maintenant la démarche pour provoquer le problème de façon systématique et même le reproduire après correction. Ce que je fais n'est pas spécialement anormal. C'est pour cela qu'il m'a fallu un certain temps pour admettre ce comportement.

Coeur Noir a écrit :

Nota. je n'utilise pas le mode graphique...
Ah bon ? Ça aussi il faut que les aidants potentiels le devinent ?
Oui là il y a un reproche : depuis le temps que tu fréquentes le forum, tu sais bien que quand il s'agit d'exposer une problématique, il faut
⋅ donner des infos sur le contexte,
⋅ rester dans ce contexte le temps du diagnostic,
⋅ et possiblement jusqu'à la résolution du problème.

Je considère qu'il n'y a pas lieu d'utiliser le graphique pour gérer un problème d'appartenance à un groupe. D'ailleurs, il n'y a pas d'outil graphique pré-installé permettant de le faire.
J'ai donné cette information, lorsque j'ai vu que tu commençais à poster des captures d'écran ne servant à rien.
Devais-je aussi dire que je pas pensé à utiliser windows ....

Coeur Noir a écrit :

Maintenant que tu es dans une situation « attendue » profites-en pour faire divers essais, en te donnant chaque fois un seul objectif :
je veux que tel et tel utilisateurs puissent faire telle chose à tel endroit,
je veux que tous les membres d'un groupe puisse lire-écrire-modifier-supprimer dans tel dossier, accessible à ce groupe seulement,
je ne veux pas que l'utilisateur B efface des affaires de A dans son $HOME mais je veux bien quand même que B puisse écrire dans le $HOME de A,
etc, etc, invente-toi des situations qui mettront à l'épreuve ta gestion des droits / propriétaires / utilisateurs / groupes.
Quand tu auras trouvé les mécanismes qui te conviennent alors tu pourras appliquer grandeur nature à un système déjà plein de données existantes… sachant que là, il faudra traiter ces données ( qui portent déjà des droits plus anciens, plus forcément raccords avec la nouvelle organisation que tu veux mettre en place. )
Attention au distinguo entre droits des fichiers et des dossiers.

Mes données ne sont pas dans des partitions EXT4 et je suis le seul utilisateur du coté ubuntu. Un jour de pluie, j'y penserais au café.
mais je reste intéressé par ce problème " je souhaiterai savoir comment faire, pour que mes enfants aient un mot de passe indépendant pour ouvrir la session" qui était la question initiale donc très loin de tout ce tralala.

Coeur Noir a écrit :

Merci de changer le titre de cette discussion : tes groupes ne se comportent pas anormalement.
« Contexte multi-utilisateurs : quels droits sur et dans les $HOME ? » serait sans doute plus informatif, pour tout le monde.

Comme le comportement que j'ai vu est normal, je mettrais simplement quelque chose en rapport avec la documentation succincte de la gestion des groupes.
https://doc.ubuntu-fr.org/tutoriel/gest … e_commande.

geole · Le 13/10/2022, à 16:43

bruno a écrit :

Je me permet d'insister (lourdement ) sur le fait qu'un changement de permissions, c'est à dire propriétaire, groupe et droits d'accès est immédiat car inscrit dans les inodes comme l'a expliqué @Coeur Noir.
Par contre une modification de l'utilisateur courant (son appartenance a un ou plusieurs groupe) exige de relancer la session pour que cela soit pris en compte car c'est inscrit entre autres dans /etc/passwd, /etc/group,… qui ne sont sourcés qu'à l'ouverture de session.

Bonjour bruno
Le problème initial était ce besoin "je souhaiterais savoir comment faire, pour que mes enfants aient un mot de passe indépendant pour ouvrir ma session" avec cette solution novatrice "ln -s -T /home/parents /home/enfants'.
Curieux, j'ai essayé et assez vite déchanté. La solution standard proposée est d'utiliser les liens au niveau inférieur sur chaque dossier de données. Par exemple
"ln -s /home/parents/Documents /home/enfants/Documents"
Ne connaissant pas parfaitement les autorisations nécessaires à mettre, j'ai fait un test.
Assez rapidement je me suis rendu compte que ce n'était pas si simple que dans la documentation:
https://doc.ubuntu-fr.org/users-admin ou https://doc.ubuntu-fr.org/adduser#addgroup
Je savais déjà que les commandes chmod étaient à effet immédiat mais pas trop d'habitudes pour les groupes.
Très vite, je me suis rendu compte que la création des groupes n'était pas à effet immédiat. Pourquoi pas.
J 'ai donc quitté la session et réouvert la session en pensant que cela suffisait. Que nenni. Il fallait rebooter. Je ne trouve pas cela normal. D'où l'ouverture de cette discussion.
Lorsque tu as écrit que le reboot était inutile et que se reconnecter suffisait, j'ai pensé que mon ubuntu avait un virus. Alors j'ai réinstallé ubuntu dans un autre ordinateur. Puis fait l'action d'une certaine façon et il a alors suffit de se déconnecter et de se reconnecter.
J'étais bien perplexe. Je me suis souvenu qu'initialement, je n'avais pas fait pareil. J'ai rejoué comme initialement et il alors fallu que je reboote pour prendre en compte l'ajout du groupe. J'ai reproduit avec neuf tentatives de déconnexion/reconnexion avant le reboot et le fonctionnement. ( (Peut-être suffisait-il d'attendre une heure pour que cela se mette automatiquement à jour?).

Voila de quoi faire réfléchir.
Le contexte qui me semble le plus normal et qui ne nécessite pas de rebooter.
- Le logiciel est installé par parent qui a un droit administratif.
- Parent fabrique enfant sans droit administratif. Il fabrique le groupe et autorise enfant à modifier parent.
- Enfant se connecte et il accède à parent.
Je pense que cette façon de faire est utilisée dans quasiment 100% des cas surtout pour la gestion des serveurs.

Le contexte que j'ai utilisé et qui nécessite de rebooter.
- Le logiciel est installé par parent qui a un droit administratif.
- Parent fabrique enfant avec droit administratif.
J'ai pris ce choix car je me suis dit qu'il y aurait probablement quelque chose qui n'allait par marcher, qu'il faudrait probablement une commande avec sudo et obligation de revenir sur parent. Alors autant traiter le problème directement avec enfant et lorsque tout sera au point, supprimer le droit administratif à enfant.
Il n'y a vraiment qu'avec un ordinateur individuel qu'on peut faire ce type de choix. Il est donc certainement très rarement utilisé.
- Enfant se connecte.
Comme le mot de passe à rallonge est tellement pénible à frapper, il est supprimé ( il suffit de consulter la documentation et se souvenir que les clé USB de boot sont disponibles un peu partout).
- Enfant fabrique le groupe et s'autorise à modifier parent.
- Enfant peut maintenant passer son temps à se déconnecter et se reconnecter, il n'accédera pas à parent. Il devra rebooter.

Remarque 1. Si après reboot, on veut rejouer le scénario de refus d'accès après reconnexion, il sera nécessaire d'utiliser un autre nom de groupe qui va générer un autre numéro. C'est cela qui m'a prit un peu de temps à découvrir pour refabriquer le contexte.
Remarque 2. Comme on s'en doute, supprimer le groupe ne suffit pas à stopper immédiatement l'accès à parents.

Dernière modification par geole (Le 13/10/2022, à 16:52)

erresse · Le 13/10/2022, à 17:00

geole a écrit :

Mes données ne sont pas dans des partitions EXT4 et je suis le seul utilisateur du coté ubuntu. Un jour de pluie, j'y penserais au café.

La gestion des droits Linux s'applique aux formats de partitions Linux, pas forcément aux autres formats.
Rien ne dit que les droits que tu vas placer sur les objets de tes volumes correspondent à quelque chose de cohérent si le format de la partition est, par exemple, NTFS...

Coeur Noir · Le 13/10/2022, à 19:21

toujours aussi agréable d'essayer de t'aider ou de te faire comprendre quelque chose, Geole.

Le problème de cette discussion n'est un montage de partition. C'est totalement hors sujet.

Si, si c'est complètement dans le sujet de cette discussion ici, dans ton contexte à toi, c'est juste toi qui ne veux pas voir pourquoi.

enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée
(…)
disons qu'un point de montage est un dossier aux droits plutôt ouverts rwxr-xr-x mais les données dedans peuvent très bien être plus restrictives rwx------ ou appartenir à d'autres utilisateurs et groupes.

Si ton montage a des options qui restreignent d'une façon ou d'une autre l'usage de la partition, ou s'il s'agit de montage de système de fichiers non « linuxien » ( NTFS, Fat… )
il te faudra adopter une stratégie de droits et permissions en conséquence, qui pourra passer par des options de montage spécifiques afin d'attribuer un utilisateur et un groupe concernant alors toutes les données contenues par ce système de fichiers monté. Ou tester le « nouveau » pilote ntfs dans Linux ( et mapper les utilisateurs d'un système Windows avec ceux d'un système Linux. )

Et tout ça, ça passe fondamentalement par la compréhension des droits, permissions, utilisateurs et groupes sous Linux.
C'est constitutif du fonctionnement de ce système dans son ensemble, tu ne pourras jamais faire sans, y compris pour des données provenant de systèmes de fichiers « étrangers ».
Certes ça ne changera rien sur ces données elles-mêmes, mais ça te les rendra exploitables plus facilement quand elles sont vues à travers ton Linux.

Mes données ne sont pas dans des partitions EXT4 et je suis le seul utilisateur du coté ubuntu

Oui et ? Ce serait bien que ces données quand tu les vois depuis ton Ubuntu t'appartiennent et ne soient modifiables que par toi, ou par un groupe dont tu gères sciemment les membres, tu crois pas ?
Plutôt que rester à root:root avec droits rwxrwxrwx qui est la situation par défaut pour un système de fichiers « étranger » sans options dédiées sur le montage.
Cette situation par défaut n'est qu'un point de départ pragmatique : Linux ne comprenant pas comment se gèrent les attributs de ce système de fichiers, il laisse ça complètement ouvert et donc dangereusement à poil.
Ça ne signifie pas qu'il faut laisser ça dans cet état. C'est à toi l'administrateur système de décider comment seront attribuées ces données dans ton système.
Il ne peut pas deviner à ta place ce qui doit être fait de ces données, puisque ces données « étrangères » ne portent pas d'attributs à son attention ( elles en portent sans doute, mais à l'attention d'un autre OS. )

Doooonc… si tu ne passes pas la bonne option de groupe au montage qui utilise le dossier SDD15, les données montées appartiennent peut-être à un groupe dont enfants n'est pas membre.
Ou elles sont bien au groupe dont enfants est membre mais le groupe n'a pas le droit d'écriture.
Ce qui pourrait expliquer l'échec d'écriture dans le fichier avvvv ( si SDD15 était un point de montage à ce moment-là )
Il faut donc aussi préciser à ce montage les masques ou modes nécessaires sur fichiers et dossiers, afin que le groupe aient les droits que tu juges utiles dans ce cas.
Les droits que tu mets sur le dossier SDD15 ne concernent que ce dossier dans Linux.
Si ce dossier devient un point de montage pour un système de fichier étranger à Linux alors c'est dans les options du montage que tu précises les attributs des données montées.

A y est, tu vois pourquoi ça peut être important de vérifier les options des montages ? Et pourquoi ça peut être relié à ton contexte, qui n'est pas 100% identique à celui de Goliath60 dans l'autre discussion ?

je reste intéressé par ce problème " je souhaiterai savoir comment faire, pour que mes enfants aient un mot de passe indépendant pour ouvrir la session" qui était la question initiale donc très loin de tout ce tralala.

Problème résolu depuis un moment déjà, c'est toi qui t'égares. Problème qui n'est pas le sujet de ce fil, que tu as créé ici car là-bas tu n'avais pas eu de réponse à ta question ( donc tu as bien fait de créer ce fil. )

Mais il est inutile que tu continues d'intervenir dans cette discussion car tu t'égares.

L'hôpital qui se fout de la charité. Bravo.
Ben si faut bien que je réponde, ça me chagrinerait que les autres lecteurs de cette discussion suivent ton exemple

Dernière modification par Coeur Noir (Le 13/10/2022, à 23:59)

Coeur Noir · Le 13/10/2022, à 19:42

geole a écrit :

Voila de quoi faire réfléchir.
(…)
Le contexte que j'ai utilisé et qui nécessite de rebooter.
- Le logiciel est installé par parent qui a un droit administratif.
- Parent fabrique enfant avec droit administratif.
J'ai pris ce choix car je me suis dit qu'il y aurait probablement quelque chose qui n'allait par marcher, qu'il faudrait probablement une commande avec sudo et obligation de revenir sur parent. Alors autant traiter le problème directement avec enfant et lorsque tout sera au point, supprimer le droit administratif à enfant.
Il n'y a vraiment qu'avec un ordinateur individuel qu'on peut faire ce type de choix. Il est donc certainement très rarement utilisé.
- Enfant se connecte.
Comme le mot de passe à rallonge est tellement pénible à frapper, il est supprimé ( il suffit de consulter la documentation et se souvenir que les clé USB de boot sont disponibles un peu partout).
- Enfant fabrique le groupe et s'autorise à modifier parent.
- Enfant peut maintenant passer son temps à se déconnecter et se reconnecter, il n'accédera pas à parent. Il devra rebooter.
(…)

Sous une session non-administrateur, en terminal tu peux « appeler » un autre utilisateur :
Disons que A est l'admin et B la session non admin :

B@machine:~$ su A
Mot de passe : 
A@machine:/home/B$

Quand tu en as fini avec A et ses commandes en sudo, pour redevenir B :

A@machine:/home/B$ exit
exit
B@machine:~$

→ su pour switch substitute user ( voir remarque de Bruno ci-après ).

Et en fait, c'est un peu idem depuis des utilitaires graphiques d'administration : ils demanderont le mot de passe d'un utilisateur admin. L'humain B ne doit donc pas connaître ce mot de passe. Mais l'humain A ( qui connaît son mot de passe sudo ) peut très bien lancer depuis la session B un utilitaire graphique d'administration, par ex. Paramètres / Utilisateurs ou gparted ou synaptic…

En fait je n'avais pas compris que tu te compliquais la vie.

L'histoire de la déco de session ou du reboot pour effectivement voir les modifications de droits s'effectuer reste à éclaircir : j'ai l'impression que c'est variable d'un environnement de bureau à l'autre ( ou j'ai juste eu de la chance ).

Dernière modification par Coeur Noir (Le 13/10/2022, à 20:26)

bruno · Le 13/10/2022, à 19:56

Pourquoi su (substitute user) ?
Cela fonctionne très bien avec sudo (subsititute user do), pour se substituer à l'utilisateur toto et lancer commande :

sudo -u toto commande

ou pour ouvrir un shell en tant que toto :

sudo -u toto -i

On utilise plutôt su sur un système ou sudo n'est pas installé ou pour passer root si le compte est actif avec un mot de passe.

Coeur Noir · Le 13/10/2022, à 20:52

Pourquoi …pas ? Fainéantise, essentiellement.
Y'a un danger à utiliser su dans ce cas ?
https://man7.org/linux/man-pages/man1/su.1.html
J'ai l'impression que c'est safe tant qu'on précise bien un utilisateur ( de toute façon sous Ubuntu, su tout court échoue puisque root n'a pas son propre mot de passe. )
Je m'en sers pas tous les jours mais depuis des années, donc je ne suis peut-être jamais « tombé » dans un cas piégeant…

Mais je note. Et merci.

On sort comment du shell, pareil exit ?

Dernière modification par Coeur Noir (Le 13/10/2022, à 22:52)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 12/10/2022, à 18:12

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#27 Le 12/10/2022, à 22:13

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#28 Le 12/10/2022, à 22:34

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#29 Le 12/10/2022, à 23:04

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#30 Le 13/10/2022, à 00:17

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#31 Le 13/10/2022, à 14:43

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#32 Le 13/10/2022, à 16:43

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#33 Le 13/10/2022, à 17:00

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#34 Le 13/10/2022, à 19:21

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#35 Le 13/10/2022, à 19:42

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#36 Le 13/10/2022, à 19:56

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

#37 Le 13/10/2022, à 20:52

Re : [Résolu] Précisions sur la gestion d'un groupe d'utilisateurs

Pied de page des forums