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

geole · Le 11/10/2022, à 16:42

Bonjour
Suite à cet échange sans réponse et afin de ne pas alourdir la discussion, j'ouvre celle-ci avec un nouveau contexte et un autre ordinateur toujours en 22.04

Je (enfants) veux donc écrire dans le répertoire d'un autre utilisateur (a)

enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxr-xr-x  2 a    famille       4096 août  11 22:02 SDD15
enfants@b:~$ grep famille /etc/group
famille:x:1002:a,enfants

Si je comprends bien, on voit que le répertoire SDD15 n'est pas en écriture pour l'entité famille.

enfants@b:~$ echo a >/home/a/SDD15/a
bash: /home/a/SDD15/a: Permission non accordée

Cette erreur est donc normale. Je pensais qu'il suffisait d'autoriser avec cette commande (auparavant je faisais 771)

enfants@b:~$ sudo chmod g+rwx /home/a/SDD15

Puis de relancer

enfants@b:~$ echo a >/home/a/SDD15/a
bash: /home/a/SDD15/a: Permission non accordée
enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxrwxr-x  2 a    famille       4096 août  11 22:02 SDD15

Mais cela ne fonctionne pas. Si je précède par "sudo", cela fonctionne.
J'ai aussi essayé avec famille contenant "root" et "enfants" ainsi que seulement "enfants" sans aucun succès.
Je vous demande donc votre aide sachant que cet ensemble de commandes fonctionnent.

enfants@b:~$ sudo chmod g-rwx,o+rwx /home/a/SDD15
enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwx---rwx  2 a    famille       4096 août  11 22:02 SDD15
enfants@b:~$ echo a >/home/a/SDD15/a
enfants@b:~$ cat /home/a/SDD15/a
a
enfants@b:~$

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

Coeur Noir · Le 12/10/2022, à 04:03

Coucou !

Rassure-toi, tes permissions se comportent normalement ;-) Y'a peut-être juste une blague de l'environnement Gnome et quelques subtilités qui te manquent…
Subtilités qui sont rarement exposées dans les doc's « tout public » qui oublient, volontairement ou par ignorance ou pour soi-disant simplification,
le caractère fondamentalement multi-utilisateurs d'un système Linux.

Déjà résumons la situation :

enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxr-xr-x  2 a    famille       4096 août  11 22:02 SDD15

Là c'est donc le dossier /home/a/SDD15 qui a pour propriétaires l'utilisateur a ET le groupe famille.
→ un élément ( fichier ou dossier ) compte deux propriétaires : un utilisateur ET un groupe ; un élément peut donc appartenir à plusieurs utilisateurs membres de son groupe.
→ un élément n'appartient qu'à un seul groupe MAIS un utilisateur peut faire partie de plusieurs groupes.

enfants@b:~$ grep famille /etc/group
famille:x:1002:a,enfants

Les utilisateurs a et enfants sont membres du groupe famille.

enfants@b:~$ echo a >/home/a/SDD15/a

à ce moment là, ça échoue, ok, donc tu ajoutes le droit d'écriture au groupe sur le dossier SDD15

enfants@b:~$ sudo chmod g+rwx /home/a/SDD15

et là ça échoue encore, c'est vrai que c'est bizarre…

…mais tu es sous Gnome/Ubuntu ?

Quitte et relance ta session enfants, voire redémarre, ça devrait alors prendre en compte les modifications.
Je ne saurais dire si c'est un bug ou un mécanisme volontaire mais je remarque aussi sous Ubuntu/Gnome 22.04 que manipuler certains droits et permissions concernant les groupes n'a pas toujours d'effet immédiat,
comme si ( hypothèse de ma part ) cette information n'était traitée qu'au lancement de la session ?

Continuons.

Crée un fichier nommé test01 dans /home/a/SDD15/

touch /home/a/SDD15/test01

ou

echo test01 >/home/a/SDD15        # si tu préfères cette formulation

Ça fonctionnera [ sous 20.04 ou les $HOME sont en 755 ] car avec

enfants@b:~$ sudo chmod g+rwx /home/a/SDD15

le dossier SDD15 donne dorénavant aux membres du groupe famille le droit d'écrire des éléments DANS CE dossier SDD15.

Maintenant crée aussi un dossier dans SDD15 :

enfants@b:~$ mkdir /home/a/SDD15/test02

Et stop, regardons le contenu de SDD15 :

enfants@b:~$ ls -la /home/a/SDD15

tu verras que test01 et test02 appartiennent à enfants:enfants ; le fichier avec des droits rw-r----- et le dossier avec des droits rwxr-x---
( ça veut dire entre autres que personne à part enfants ne saura écrire dans le dossier test02 ni ne saura modifier ou écrire dans le fichier test01 )

L'appartenance à l'utilisateur enfants est facile à comprendre : c'est enfants qui agit, qui a créé ces éléments, ils lui appartiennent.

Tu l'auras déjà remarqué, un utilisateur est ( souvent ) membre de plusieurs groupes : à un utilisateur est associé un groupe principal ( primary group ) qui par défaut sous Ubuntu ( et la plupart des distributions Linux ) a le même nom que l'utilisateur. Les autres groupes dont il est membre sont les groupes secondaires ( secondary or supplementary groups ).
Bref, là-aussi l'appartenance au groupe enfants est normale, situation par défaut.

Les droits rwxr-x-- sont eux aussi normaux : lorsqu'un utilisateur crée un élément, le système le rend propriétaire de cet élément et applique à cet élément le UMASK global,
qui est par défaut sous Ubuntu 027 [ à vérifier ] → soit droit 750 rwxr-x---

Ces mécanismes ( et d'autres ) qui définissent les groupes primaires et droits des utilisateurs sont consignés dans le fichier /etc/login.defs ( lis-le, il est très commenté et explicatif, mais ne le modifie pas ) ;
les valeurs par défaut viennent de là. On pourrait intervenir sur ce fichier système global mais restons prudents : il a beaucoup de conséquences, à évaluer finement, c'est bien quand on fait de l'administration système « large », à la maison pour quelques utilisateurs et groupes on peut s'en passer ;-)

Il y a plus « simple » ou disons plus circonscrit : le bit sgid ou droit spécial de groupe qu'on peut appliquer à un dossier. Par analogie grossière c'est un peu le concept d'héritage sous Windows.
DANS un dossier qui accorde ce droit spécial au groupe, tout élément créé se verra attribuer le groupe et les droits de ce dossier « parent », contenant.

Revenons à ta situation dans la session enfants et ajoutons ce bit sgid à ton dossier SDD15

sudo chmod g+s,o-rwx /home/a/SDD15

ou

sudo chmod 2770 /home/a/SDD15

Regarde les droits du dossier SDD15, dorénavant ça devrait être rwxrws--- et toujours a:famille ;
maintenant crée un fichier test03 et un dossier test04

touch /home/a/SDD15/test03
mkdir /home/a/SDD15/test04

puis

ls -la home/a/SDD15

test03 devrait montrer rw-rw---- et enfants:famille ;
test04 devrait montrer rwxrwx--- et enfants:famille
→ les éléments créés ont « hérité » du groupe propriétaire de SDD15 et des droits de ce groupe ( rw- pour le fichier et rwx pour le dossier ).
→ ici les éléments appartiendront indifféremment aux utilisateurs a ou enfants ( selon qui les créé ) et ils appartiennent forcément au groupe famille qui est « imposé » grâce au bit sgid sur SDD15
→ note au passage que test01 et test02, eux, n'ont pas bougé car ils ont été créés AVANT que le dossier SDD15 porte le bit sgid.

Là, une fois dans la session de a ; comme l'utilisateur a est membre du groupe famille, groupe auquel les éléments donnent le droit d'écriture, a pourra écrire, modifier, supprimer DANS ces éléments même si ces éléments appartiennent aussi à l'utilisateur enfants.

Voilà donc un dossier SDD15 partagé en écriture pour uniquement les membres du groupe famille, les utilisateurs a et enfants.

Si tu ne dois partager un dossier en écriture qu'entre deux utilisateurs a et b, tu peux te contenter d'ajouter l'utilisateur a au groupe de b et l'utilisateur b au groupe de a, pas besoin de créer un nouveau groupe ( c'est un intérêt des groupes au même nom que l'utilisateur. )

Rappels :
⋅ un élément qui accorde des droits rwx aux autres est une faille de sécurité ;
⋅ le mot de passe de l'utilisateur administrateur ne doit pas jamais divulgué,
⋅ dans un contexte multi-utilisateurs « conséquent », la session de l'administrateur devrait être cachée et ne servir qu'à l'administration, rien d'autre.

Tu peux aussi lire ou relire :
droits ⋅ permissions ⋅ sticky bits ⋅ Add user to group
et l'échange que tu évoques, à partir du #36 et les retours à partir du #41.

[ edit 1 ] attention aussi aux droits et permissions portées par les points de montage des partitions concernées !
Ils doivent être en rwxr-xr-x et peuvent rester propriété de root:root
Dans un contexte multi-utilisateurs, les droits r-x pour les autres sont primordiaux sur les points de montage ( présentant des données à l'attention de plusieurs utilisateurs ).

[ edit 2 ] si malgré ces réglages de droits et permissions sur le dossier SDD15 les commandes touch ou echo ou mkdir échouent encore à créer de nouveaux éléments,
alors tente de créer de nouveaux éléments depuis des appli's « graphiques » ( Nautilus, Gedit, LibreOffice ou autres… )
S'il y a une différence de comportement selon que tu passes par une commande ou une appli' graphique alors il faudra modifier la valeur de UMASK dans /etc/login.defs ( c'était un bug' dans Gnome normalement résolu… )

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

iznobe · Le 12/10/2022, à 07:33

c ' est plutot normal , tu n' es pas le propietaire de l' element , tu ne peux donc pas en changer les permissions . enfants est un utilisateur faisant parti du groupe , donc pas proprietaire .
d ' ou l' utilisation de sudo .
par contre sans sudo c' est possible avec l' utilisateur " a " d ' attribuer le droit d' ecriture au groupe famille .

Dernière modification par iznobe (Le 12/10/2022, à 07:37)

geole · Le 12/10/2022, à 09:10

Bonjour.
Je vais faire les tests après relance Et regarder sticky. ( je suis actuellement connecté en Ipad)

Vous m'expliquer clairement que quelqu'un du groupe famille ne peut pas écrire sans utiliser sudo.
Alors qu'en faisant la même démarche sur le groupe others, tout se passe bien.
Cela me semble malgré tout illogique.

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

bruno · Le 12/10/2022, à 09:33

Bonjour,

Commandes étranges…

Je n'ai pas lu la première réponse (trop longue) mais peut-on voir les retours de :

namei -omv /home/a/SDD15/a

et

getent group famille

Si un membre du groupe famille ne peut pas écrire dans le fichier a c'est qu'il n'a pas les droits d'accès suffisant sur le fichier (c'est bon avec le rw pour le groupe) ou sur un des dossiers parent.

Dernière modification par bruno (Le 12/10/2022, à 13:32)

erresse · Le 12/10/2022, à 10:58

bruno a écrit :

Je n'ai pas lu la première réponse (trop longue) mais peut-on voir les retours de :

Hé bien c'est un tort !
Une telle réponse qui explique clairement le fonctionnement des droits d'accès est tout bénéfice, il est au contraire impératif de la lire in-extenso.
Mais pour toi qui utilises le système depuis longtemps, ces arcanes ne sont peut-être plus des secrets et tu peux te dispenser de lire les explications. Pourtant geole n'est pas non plus un débutant et s'il pose la question, c'est qu'il n'a pas tout bien assimilé et que la réponse (que tu estimes trop longue) de Cœur Noir lui sera certainement précieuse...

Dernière modification par erresse (Le 12/10/2022, à 10:59)

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

geole a écrit :

Vous m'expliquer clairement que quelqu'un du groupe famille ne peut pas écrire sans utiliser sudo

Non. Pas du tout. Personne ne suggère cela. Tout le contraire même. Relis tranquillement et à tête reposée les docs et exemples proposés, teste les diverses commandes pour en voir les effets.

Les membres d'un groupe peuvent écrire dans un dossier SI ce dossier accorde des droits d'écriture à ce groupe.
[ edit ] Et si tout le chemin jusqu'à ce dossier est lisible~traversable par les membres du groupe.
Ce qui n'est plus la situation par défaut des $HOME sous 22.04 qui sont en 750 ; ils étaient en 755 autrefois donnant aux autres ( à tous ) la possibilité de lire~traverser les divers $HOME. Ça n'est plus le cas.

sudo ne sera nécessaire « qu'une fois » pour mettre en place les droits adéquats sur les éléments car effectivement seul l'utilisateur propriétaire d'un élément ( ou le super-utilisateur root ) peut en changer les droits.
Ensuite, à l'usage, au quotidien, plus besoin de sudo sinon ça n'aurait pas d'intérêt.

Si tu ne veux pas du tout te servir de sudo alors agis depuis la session a pour changer les droits d'éléments appartenant à a ; depuis la session enfants pour des éléments appartenant à enfants ; depuis la session truc pour des éléments appartenant à truc, etc, etc. C'est logique et légitime que seul l'utilisateur propriétaire d'un élément ait ce genre de « pouvoirs » sinon à quoi servirait la notion de propriétaire → n'importe qui pourrait faire n'importe quoi avec n'importe quel élément ?

Dans des systèmes de fichiers compatibles Linux, ces attributs ( propriétaires, droits… ) sont portés directement par les éléments eux-mêmes, ils sont inscrits dans les inode des fichiers et dossiers eux-mêmes, c'est dans la fondation même du système de fichiers dans son ensemble.

______________________________________

Digression mais c'est pas grave puisque Bruno ne lira pas ;-)

Un élément accordant aux autres des droits rwx est une faille de sécurité : c'est un élément exploitable par n'importe qui. On ne donne pas au monde entier le droit d'écrire dans un système.

À la rigueur on peut donner de tels droits aux autres sur un système de fichiers dans un support de données nomade, externe au système ( type DD externe ou clé usb… ) : ces types de support amovibles~connectables~à~chaud sont par défaut et automatiquement montés dans un emplacement restreint à l'utilisateur de la session en cours ( merci udisks, udisksctl et leur utilisation d'ACL dans /media/$USER ).
Les ACL sont une autre façon de gérer les questions de droits et permissions, plus granulaire ou circonscrite ou « à exceptions » ; là où la façon classique malgré les multiples combinaisons qu'elle offre aura un effet « tout ou rien ».

Il y a au moins une exception notable dans un système : le dossier /tmp avec droits rwxrwxrwt → DANS ce dossier, le sticky bit t donne seulement au propriétaire d'un élément la possibilité de le supprimer.
Ou un dossier corbeille multi-utilisateurs .Trash qui serait construit sur le même modèle de permissions. Ça en fait des dossiers que n'importe qui peut facilement atteindre et il faut considérer ce risque : ce sont aussi les seuls dossiers qu'un « utilisateur étranger au système » pourrait atteindre.

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

geole · Le 12/10/2022, à 13:03

Bonjour
Quelques retours
Tout d'abord, le problème semble résolu, Déconnecter la session n'est pas suffisant, Il faut arrêter l'ordinateur.
Comme c'est un ordinateur personnel, il s'arrête quasiment tous les jours.
Mais que se passerait-il si c'était un serveur que ni s'arrête jamais.
J'ai donc refabriqué le contexte.
En voici le retour.
1) Préparation.

enfants@b:~$ sudo addgroup test1
Ajout du groupe « test1 » (GID 1004)...
Fait.
enfants@b:~$ sudo adduser enfants test1
Ajout de l'utilisateur « enfants » au groupe « test1 »...
Ajout de l'utilisateur enfants au groupe test1
Fait.
enfants@b:~$ sudo chown -R a:test1 /home/a
enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxrwx---  2 a test1       4096 oct.  12 13:41 SDD15

2) Le test classique

enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée

3) Le test avec une permission supplémentaire

enfants@b:~$ sudo chmod g+s,o-rwx /home/a/SDD15
enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée
enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxrws---  2 a test1       4096 oct.  12 13:41 SDD15
enfants@b:~$ sudo chmod 2770 /home/a/SDD15
enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée
enfants@b:~$ ls -ls /home/a | grep SDD15
      4 drwxrws---  2 a test1       4096 oct.  12 13:41 SDD15

4) Le premier type de contrôle

enfants@b:~$ ls -la /home/a/SDD15
ls: impossible d'ouvrir le répertoire '/home/a/SDD15': Permission non accordée

5) Le second type de contrôle

enfants@b:~$ name -omv /home/a/SDD15/a*
La commande « name » n'a pas été trouvée, voulez-vous dire :
  commande « namei » du deb util-linux (2.37.2-4ubuntu3)
  commande « nama » du deb nama (1.216-1)
  commande « uname » du deb coreutils (8.32-4.1ubuntu1)
  commande « mame » du deb mame (0.242+dfsg.1-1)
  commande « named » du deb bind9 (1:9.18.1-1ubuntu1.2)
  commande « nam » du deb nam (1.15-5.2)
  commande « lame » du deb lame (3.100-3build2)
  commande « nvme » du deb nvme-cli (1.16-3build1)
Essayez : sudo apt install <nom du deb>
enfants@b:~$ getent group test1
test1:x:1004:enfants
enfants@b:~$

Je vais donc maintenant refaire une tentative de déconnexion/reconnexion et d'arrêt machine pour confirmation.
Bien entendu, je suis en dé-accord avec l'arrêt machine comme solution pérenne.

===> Je confirme qu'un redémarrage est nécessaire. Si ce n'est pas un bug, il faudrait indiquer dans la documentation qu'un redémarrage est nécessaire.
Je ne sais pas si c'est nouveau ou si cela a toujours fonctionné de celle façon. => J'ai une version 16.04 récemment installée.

J'ai aussi constaté qu'en supprimant le groupe et en réallouant correctement
sudo chown -r a:root /home/a
enfants continue de pouvoir écrire dans /home/a
cela ressemble à un contrôle installé au démarrage de l'ordinateur et jamais mis à jour

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

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

Bien entendu, je suis en dé-accord avec l'arrêt machine comme solution pérenne.

Hélas, si tu utilises l'environnement graphique Gnome je crois que tu n'auras pas trop le choix. Et je partage ton avis, c'est foutrement pas pratique.

Mais que se passerait-il si c'était un serveur que ni s'arrête jamais

Si c'était un serveur, il n'aurait peut-être pas d'interface graphique… Ou il ne serait pas sous Gnome…

MAIS quoi qu'il en soit, ces questions d'administration des droits et permissions, tu ne les mets en place qu'une seule fois, une bonne fois pour toutes, tu n'es pas censé revenir dessus tous les jours.

En gros si tous les jours tu dois intervenir sur ces questions de droits et permissions, c'est que tu n'as pas encore trouvé l'organisation qui te convient ( et c'est normal de ne pas la trouver du premier coup ) :
c'est typiquement le genre d'exercice qui nécessite d'évaluer tes besoins ( en tant qu'administrateur du système ) et les besoins des divers utilisateurs ( en tant …qu'utilisateurs « simples » non administrateurs, leurs besoins de partages de données non système ) afin d'établir un « plan », une structure, une arborescence de dossiers qui répondra bien à ces besoins.
Bref c'est les joies de l’administration système, ah ah ! Et tu verras qu'on peut y prendre goût…

(Re)lis le #7 → nos réponses se sont croisées : je mets longtemps à écrire, et à corriger~modifier puisque je fais des réponses trop longues au goût de certains

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

bruno · Le 12/10/2022, à 13:34

Désolé la commande demandée (faute de frappe) était :

namei -omv /home/a/SDD15/a

Il n'y a heureusement aucun besoin de redémarrer l'ordinateur pour que les changements de permissions soient pris en compte. Par contre la modification de l'utilisateur courant (changement de groupe, ajout à un groupe etc.) peut nécessiter de relancer le shell.

Et je ne vois pas pourquoi tu essaies de placer le SGID (chmod g+s) sur ton dossier, cela ne semble avoir rien à voir avec ton problème.

Dernière modification par bruno (Le 12/10/2022, à 13:45)

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

Par contre Geole, si tu veux qu'on « t'aide » s'il te plaît ne change pas trop de contexte en cours de route.

Là dans ton #8 ça :

enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée

n'est déjà pas normal, enfants est membre du groupe test1, et SDD15 donne bien le droit d'écriture au groupe, donc pourquoi ça coince ?

Parce qu'au-dessus de SDD15 enfants ne peut pas ouvrir le dossier /home/a sans doute parce que /home/a est en droit 750 appartenant à a:a, la situation par défaut pour un $HOME sous 22.04.
C'est ce que proposait de vérifier Bruno via :

namei -omv /home/a/SDD15/a

namei permet de lister les droits de tous les éléments d'un chemin.

Des solutions :

sudo chmod 755 /home/a

qui permet à n'importe qui de voir ce qu'il y a dans ce $HOME ( leur ancien mode par défaut )
ou

sudo chown a:test1 /home/a
sudo chmod 750        # suffisant pour un accès en lecture pour le groupe

ou encore

sudo adduser enfants a

…après ça dépend qui tu mets dans quel groupe, sur quel dossier tu mets du rwxr-x--- ou du rwxrwx---

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

Coeur Noir · Le 12/10/2022, à 14:05

bruno a écrit :

Par contre la modification de l'utilisateur courant (changement de groupe, ajout à un groupe etc.) peut nécessiter de relancer le shell.

Mmmm… ah oui ça a l'air de ressembler à ce que je constate … sous Gnome/Ubuntu 22.04.
Alors que sous Budgie 20.04 ( pourtant un shell assez proche de Gnome ) je n'ai pas besoin de relancer la session pour voir l'effet de ce genre de modifications ( l'un est plus prudent que l'autre ? )

Et je ne vois pas pourquoi tu essaies de placer le SGID (chmod g+s) sur ton dossier, cela ne semble avoir rien à voir avec ton problème.

Effectivement, ça c'est pour donner aux membres du groupe la possibilité d'écrire et modifier dans SDD15 des éléments appartenant indifféremment aux divers membres du groupe test1 ( groupe propriétaire de SDD15 ), c'est une autre problématique.

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

geole · Le 12/10/2022, à 14:12

Pour l'instant je n'ai touché à rien hormis redémarrer

enfants@b:~$ namei -omv /home/a/SDD15/a
f: /home/a/SDD15/a
drwxr-xr-x root root  /
drwxr-xr-x root root  home
drwxr-xr-x a    test1 a
drwxrws--- a    test1 SDD15
-rw-rw-r-- a    test1 a
enfants@b:~$

J'ai oublié

sudo chmod  -R 771 /home/a

Donc du coup

sudo chmod -R 771 /home/a

enfants@b:~$ sudo addgroup test2
Ajout du groupe « test2 » (GID 1005)...
Fait.

enfants@b:~$ sudo addgroup enfants test2
Ajout de l'utilisateur « enfants » au groupe « test2 »...
Ajout de l'utilisateur enfants au groupe test2
Fait.

enfants@b:~$ sudo chown -R a:test2 /home/a
enfants@b:~$ echo b>/home/a/SDD15/bbbb
bash: /home/a/SDD15/bbbb: Permission non accordée

enfants@b:~$ namei -omv /home/a/SDD15/a
f: /home/a/SDD15/a
drwxr-xr-x root root  /
drwxr-xr-x root root  home
drwxrwx--x a    test2 a
drwxrws--x a    test2 SDD15
-rwxrwx--x a    test2 a
enfants@b:~$

enfants@b:~$ ls -ls /home/a
ls: impossible d'ouvrir le répertoire '/home/a': Permission non accordée
enfants@b:~$ sudo ls -ls /home/a
total 1060324
....
      4 drwxrwx--x  2 a test2       4096 oct.   8 20:07 Documents
      4 drwxrwx--x  2 a test2       4096 août  11 22:01 DOWNLOAD
      4 drwxrwx--x  2 a test2       4096 août  11 22:01 Downloads
......
      4 drwxrwx--x  2 a test2       4096 oct.  11 16:53 SDD14
      4 drwxrws--x  2 a test2       4096 oct.  12 14:09 SDD15
      4 drwxrwx--x  2 a test2       4096 août  11 22:02 SDD16

Je vais tenter de ne pas rebooter.

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

geole · Le 12/10/2022, à 14:31

enfants@b:~$ echo b>/home/a/SDD15/bbbb
bash: /home/a/SDD15/bbbb: Permission non accordée
enfants@b:~$ sudo chmod -R g+s /home/a
enfants@b:~$ echo b>/home/a/SDD15/bbbb
bash: /home/a/SDD15/bbbb: Permission non accordée
enfants@b:~$

~$ sudo ls -als /home
total 28
4 drwxr-xr-x  7 root    root    4096 oct.  11 16:10 .
4 drwxr-xr-x 27 root    root    4096 oct.   8 00:00 ..
4 drwxrws--x 45 a       test2   4096 oct.  12 13:26 a
4 drwxr-xr-x  2 root    root    4096 mai   30 13:20 b
4 drwxr-xr-x  2 root    root    4096 mai   30 13:20 c
4 drwxr-xr-x  2 root    root    4096 mai   30 13:20 d
4 drwxr-xr-x 14 enfants enfants 4096 oct.  11 19:54 enfants
enfants@b:~$ sudo ls -als /home/a
total 1060400
      4 drwxrws--x 45 a    test2       4096 oct.  12 13:26 .
      4 drwxr-xr-x  7 root root        4096 oct.  11 16:10 ..
      4 drwxrws--x  3 a    test2       4096 août  11 22:01 a
      4 drwxrws--x  2 a    test2       4096 oct.   3 13:27 A
      4 -rwxrws--x  1 a    test2       3412 oct.   1 12:55 A-lire.txt
      4 -rwxrws--x  1 a    test2        591 août  11 22:00 backup.log
      4 drwxrws--x  2 a    test2       4096 août  11 22:01 BAD
     24 -rwxrws--x  1 a    test2      22226 oct.  12 13:26 .bash_h
....

Et cela fonctionne nickel en version 16.04.7

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

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

On écrit en même temps…
Relis cette discussion, la remarque de Bruno m'a fait ajouter des infos ici et là.
Relis l'autre discussion, avec Goliath60, chez qui tout va bien.

__________________

Du 771 a-t-il le moindre intérêt ?

sur des dossiers → 775|770 ou 755|750
sur des fichiers → 664|660 ou 644|640 ( on rend exécutable au cas par cas les fichiers qui le requièrent vraiment : scripts, « programmes », applications… )
→ permettre au groupe de modifier ( écrire dans ) les fichiers 660 et d'écrire dans les dossiers 770
→ permettre aussi aux autres de voir les fichiers 664 et de voir~traverser les dossiers 775

La chronologie des opérations, des diverses modifications de droits et créations d'éléments est importante…
Car ça :

drwxr-xr-x a    test1 a		→ c'est du 755
drwxrws--- a    test1 SDD15	→ c'est du 2770
-rw-rw-r-- a    test1 a		→ c'est du 664

ne me semble pas correspondre à du 771 ? ? ? ( et je dirais : tant mieux. )

En plus tu aurais fait du récursif ( -R ) 771 → soit donner l'exécution à tous les dossiers ( ok ) ET tous les fichiers ( pas ok ) pour eux ça ne sert à rien la plupart du temps dans un $HOME où les fichiers sont lancés à travers des applications graphiques, et non exécutés directement.

Bref si tu as fait ça « tôt » t'es plus du tout dans le contexte prudent « par défaut » du $HOME et tu as déjà donné au groupe des droits d'écriture dans tous les éléments de ce /home/a : pourquoi pas, mais était-ce bien le but ?
J'avais la nette impression que tu voulais seulement que SDD15 soit un partage en écriture pour le groupe.
Mmm… vu le nom, s'agit-il du point de montage d'une partition d'un SSD ?

S'il te plaît Geole, pose-toi, lis les doc's droits et permissions déjà évoquées, avant de « faire » des choses sans comprendre → c'y est expliqué pourquoi traiter fichier et dossiers différemment, et comment le faire, et comment « revenir » en arrière au cas où…

Ce qui rend d'autant plus étonnant cet échec :

enfants@b:~$ echo a>/home/a/SDD15/avvvv
bash: /home/a/SDD15/avvvv: Permission non accordée

Voir les [ edit 1 et 2 ] du message #2 : je pense qu'il y a d'autres points à vérifier, d'autres tests à faire :
⋅ quel est ton contexte d'organisation de disques, partitions et ( droits sur d'éventuels ) points de montage ?
⋅ y-a-t-il une différence de comportement selon que tu crées de nouveaux éléments via commandes ou via applications graphiques ?

Mais quoi qu'il en soit les essais, tests sont à faire dans un contexte clairement défini : pars d'une situation la plus neutre possible, la plus « défaut, basique » possible.

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

bruno · Le 12/10/2022, à 15:33

j'ai du mal à suivre

Le premier retour en #13 montre que a et les membres du groupe test1 peuvent écrire dans le fichier /home/a/SDD15/a. Mais tu ne fais pas le test…

Ensuite tu modifies l'utilisateur courant en l'ajoutant au groupe test2 :

enfants@b:~$ sudo addgroup enfants test2

Pour que cela soit pris en compte il faut relancer la session avec l'utilisateur enfants. Il faut de toute façon contrôler avec la commande :

groups

(Également pour que @Coeur Noir puisse vérifier que quel que soit le système utilisé il faut relancer la session après modification de l'utilisateur courant)

Enfin ce retour :

enfants@b:~$ ls -ls /home/a
ls: impossible d'ouvrir le répertoire '/home/a': Permission non accordée

est normal puisqu’entre temps tu as modifié les permissions sur /home/a de sorte que seul le propriétaire a et les membres du groupe test2 peuvent entrer dans ce répertoire.
Et tant que tu n'as pas relancé la session, le shell courant « ignore » que enfants est membre du groupe test2.
CQFD

Dernière modification par bruno (Le 12/10/2022, à 15:46)

Coeur Noir · Le 12/10/2022, à 15:40

@Geole De mieux en mieux, tu as aussi fait un chmod -R g+s

Le g+s tu verras plus tard ; là on a un autre mystère à résoudre et on n'y arrivera pas tant que tu fais n'importe quoi tout seul dans ton coin sans « suivre » ce qu'on te propose : où as-tu vu du chmod -R g+s dans cette discussion ou dans l'autre ??? Où as-tu vu du 771 dans cette discussion ou dans l'autre ???

Ni là :

https://forum.ubuntu-fr.org/viewtopic.php?pid=22608618#p22608618 a écrit :

Revenons à ta situation dans la session enfants et ajoutons ce bit sgid à ton dossier SDD15
sudo chmod g+s,o-rwx /home/a/SDD15

Ni là :

https://forum.ubuntu-fr.org/viewtopic.php?pid=22608364#p22608364 a écrit :

3⋅ pour que tout élément qui sera créé dans des dossiers de /home/enfants accorde les droits lecture-écriture à vadee ( via le groupe enfants dont il est membre ) :
find /home/enfants/ -type d -exec sudo chmod -c 2775 {} \;        # application du bit sgid uniquement aux dossiers contenus dans /home/enfants/

@Bruno merci.

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

Coeur Noir · Le 12/10/2022, à 15:44

geole a écrit :

Et cela fonctionne nickel en version 16.04.7

Parce que le $HOME y est par défaut en mode 755,
parce qu'on n'a pas besoin d'y relancer le shell pour « voir » les effets de certains changements de droits et permissions.
Points déjà évoqué dans cette discussion.

bruno · Le 12/10/2022, à 15:51

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.

Coeur Noir · Le 12/10/2022, à 16:31

HS quoi que…

Bruno a écrit :

/etc/passwd, /etc/group,… qui ne sont sourcés qu'à l'ouverture de session

Mmm… et je ne m'en serais aperçu que sous Gnome 22.04 et pas les ±12 années précédentes sous d'autres environnements ? ( je suis toujours dans des contextes multi-utilisateurs. )
Ou coup de bol j'aurais toujours fait ce genre de manip's depuis une session admin sur d'autres utilisateurs et jamais directement depuis la session d'un utilisateur « en cours » ?
Ou c'est un aspect que les DE autres que Gnome traitent différemment ?

Je doute car ce que tu dis là paraît terriblement logique : il faut que je compare avec le contexte exact entre Gnome et autres DE.

Par contre je n'ai aucun doute sur le changement de mode par défaut des $HOME ( de 755 à 750 ) : ça a été mis en place avec la 21.10 - en tout cas après la 20.04
Avant il n'y avait besoin de rien pour voir les affaires d'un autre utilisateur. Aujourd'hui il faut choisir une stratégie ( via groupes ou via autres ).

Fin HS

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

geole · Le 12/10/2022, à 16:36

Je suis en train de vous dire que quitter la session puis re-choisir la session au moment du choix ne suffit pas.
Il faut rebooter. En tant que particulier, cela ne me dérange pas plus que cela.
Je suis en train de réinstaller un ubuntu 22.04 neuf au cas où il y aurait des résidus polluants.
Je vais changer le titre pour mettre groupe au lieu de permission

Je vais aussi refaire les modifs en étant connecté à l'administrateur au lieu du second utilisateur.

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

Coeur Noir · Le 12/10/2022, à 17:29

Je suis en train de vous dire que quitter la session puis re-choisir la session au moment du choix ne suffit pas.

On est aussi en train de te dire que ce qu'on voit de tes essais ne permet pas de valider une hypothèse plutôt qu'une autre parce que tu as fait un peu tout et n'importe quoi en même temps avec des commandes que personne n'a suggérées…

Installation de zéro, bien, utilisateur admin « chef »

Ajout d'un 2ème utilisateur normal, non admin « adjoint ».
Ajout d'un 3ème utilisateur normal, non admin « soldat ».
Fais ces 2 ajouts depuis la session admin chef via paramètres/utilisateur.

ls -la /home

pour constater que les $HOME sont en 750

Et maintenant demande-toi comment 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.

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

geole · Le 12/10/2022, à 17:48

Aussitôt que cela sera fini
Je vais créer un adjoint qui aura les mêmes pouvoirs que le chef car si le chef est défaillant, il faut le suppléer et je tenterais de le faire écrire dans les dossiers du chef. Trop tard pour le nom du chef. Il va s'appeler a et ne me dites c'est interdit par la loi. J'ai déjà fait une grande concession pour le soldat c.

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

Coeur Noir · Le 12/10/2022, à 17:53

Je vais créer un adjoint qui aura les mêmes pouvoirs que chef car si le chef est défaillant

Pourquoi pas, ce sera un quatrième utilisateur, et ce sera le deuxième avec un compte de type administrateur.
Il pourrait s'appeler « second » ou « suppleant ».

Mais le chef n'est jamais défaillant, voyons

geole · Le 12/10/2022, à 18:02

Coeur Noir a écrit :

Mais le chef n'est jamais défaillant, voyons

ALLEZ: Le boot se plante des milliers de fois et en mode en recovery et on fabrique un autre utilisateur administrateur pour comprendre.

Point 1 fait

a@a:~$ ls -la /home
total 20
drwxr-xr-x  5 root              root              4096 oct.  12 19:03 .
drwxr-xr-x 20 root              root              4096 oct.  12 18:09 ..
drwxr-x--- 15 a                 a                 4096 oct.  12 18:47 a
drwxr-x---  2 secondousuppleant secondousuppleant 4096 oct.  12 18:59 secondousuppleant
drwxr-x---  2 soldat            soldat            4096 oct.  12 19:03 soldat
a@a:~$

point 2 fait en lignes de commandes

a@a:~$ sudo addgroup army
[sudo] Mot de passe de a : 
Ajout du groupe « army » (GID 1003)...
Fait.
a@a:~$ sudo addgroup secondousuppleant army
Ajout de l'utilisateur « secondousuppleant » au groupe « army »...
Ajout de l'utilisateur secondousuppleant au groupe army
Fait.
a@a:~$ sudo chown -R :army .
a@a:~$ sudo chmod -R g+rwx .
a@a:~$ ls -la $HOME
total 72
drwxrwx--- 15 a    army 4096 oct.  12 19:08 .
drwxr-xr-x  5 root root 4096 oct.  12 19:03 ..
-rw-rwxr--  1 a    army  220 oct.  12 18:10 .bash_logout
-rw-rwxr--  1 a    army 3771 oct.  12 18:10 .bashrc
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Bureau
drwxrwx--- 11 a    army 4096 oct.  12 18:47 .cache
drwxrwx--- 11 a    army 4096 oct.  12 18:53 .config
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Documents
drwxrwxr-x  2 a    army 4096 oct.  12 18:47 .fontconfig
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Images
drwxrwx---  3 a    army 4096 oct.  12 18:41 .local
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Modèles
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Musique
-rw-rwxr--  1 a    army  807 oct.  12 18:10 .profile
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Public
drwxrwx---  4 a    army 4096 oct.  12 18:42 snap
-rw-rwxr--  1 a    army    0 oct.  12 19:08 .sudo_as_admin_successful
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Téléchargements
drwxrwxr-x  2 a    army 4096 oct.  12 18:41 Vidéos
a@a:~$

Point trois: On va le faire bosser en s y connectant

secondousuppleant@a:~$ ls -la
total 68
drwxr-x--- 14 secondousuppleant secondousuppleant 4096 oct.  12 19:17 .
drwxr-xr-x  5 root              root              4096 oct.  12 19:03 ..
-rw-r--r--  1 secondousuppleant secondousuppleant  220 oct.  12 18:59 .bash_logout
-rw-r--r--  1 secondousuppleant secondousuppleant 3771 oct.  12 18:59 .bashrc
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Bureau
drwx------  9 secondousuppleant secondousuppleant 4096 oct.  12 19:17 .cache
drwx------  9 secondousuppleant secondousuppleant 4096 oct.  12 19:17 .config
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Documents
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Images
drwx------  3 secondousuppleant secondousuppleant 4096 oct.  12 19:17 .local
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Modèles
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Musique
-rw-r--r--  1 secondousuppleant secondousuppleant  807 oct.  12 18:59 .profile
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Public
drwx------  3 secondousuppleant secondousuppleant 4096 oct.  12 19:17 snap
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Téléchargements
drwxr-xr-x  2 secondousuppleant secondousuppleant 4096 oct.  12 19:17 Vidéos
secondousuppleant@a:~$ ls -ls /home/a
total 36
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Bureau
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Documents
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Images
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Modèles
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Musique
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Public
4 drwxrwx--- 4 a army 4096 oct.  12 18:42 snap
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Téléchargements
4 drwxrwxr-x 2 a army 4096 oct.  12 18:41 Vidéos
secondousuppleant@a:~$ touch CHAR > /home/a/CHAR
secondousuppleant@a:~$ ls -ls /home/a
total 36
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Bureau
0 -rw-rw-r-- 1 secondousuppleant secondousuppleant    0 oct.  12 19:18 CHAR
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Documents
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Images
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Modèles
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Musique
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Public
4 drwxrwx--- 4 a                 army              4096 oct.  12 18:42 snap
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Téléchargements
4 drwxrwxr-x 2 a                 army              4096 oct.  12 18:41 Vidéos
secondousuppleant@a:~$

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

secondousuppleant@a:~$ echo essai >/home/a/essai
secondousuppleant@a:~$

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/10/2022, à 16:42

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

#2 Le 12/10/2022, à 04:03

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

#3 Le 12/10/2022, à 07:33

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

#4 Le 12/10/2022, à 09:10

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

#5 Le 12/10/2022, à 09:33

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

#6 Le 12/10/2022, à 10:58

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

#7 Le 12/10/2022, à 10:59

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

#8 Le 12/10/2022, à 13:03

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

#9 Le 12/10/2022, à 13:26

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

#10 Le 12/10/2022, à 13:34

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

#11 Le 12/10/2022, à 13:53

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

#12 Le 12/10/2022, à 14:05

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

#13 Le 12/10/2022, à 14:12

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

#14 Le 12/10/2022, à 14:31

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

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

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

#16 Le 12/10/2022, à 15:33

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

#17 Le 12/10/2022, à 15:40

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

#18 Le 12/10/2022, à 15:44

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

#19 Le 12/10/2022, à 15:51

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

#20 Le 12/10/2022, à 16:31

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

#21 Le 12/10/2022, à 16:36

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

#22 Le 12/10/2022, à 17:29

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

#23 Le 12/10/2022, à 17:48

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

#24 Le 12/10/2022, à 17:53

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

#25 Le 12/10/2022, à 18:02

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

Pied de page des forums