# \[Système de fichiers\]Droits d'écriture refusé dans un répertoire root:group\[Bullseye\] **URL:** \ **Category:** Support Debian\ **Created:** [Novembre 12, 2020, 11:14 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286 "2020-11-12T23:14:06Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 12, 2020, 11:14 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/1 "2020-11-12T23:14:06Z")
Bonsoir, La chose va pouvoir se contourner, mais c’est drôlement frustrant vis-à-vis de mon fantasme de coopération. ``` root@pammob:/home# mkdir ForUs root@pammob:/home# chown -R root:pamwork ForUs/ root@pammob:/home# chmod -R 775 ForUs/ pam@pammob:/home/ForUs$ groups pam pam : pam cdrom floppy audio dip video plugdev netdev bluetooth lpadmin scanner pamwork pam@pammob:/home/ForUs$ echo "Première participation" > Open bash: Open: Permission non accordée ``` Avec vi, c’est la même chose. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 12, 2020, 11:22 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/2 "2020-11-12T23:22:08Z")
Bonsoir, C’est normal, ton repertoire n’est autorisé que à l’utilisateur root et le groupe pamwork. Tu es user pam, donc les droits user ne s’appliquent pas, et si pam ne fait pas partie du groupe pamwork il n’a pas les droite en ecriture non plus car les others, n’ont pas le droit d’ecriture. Peux tu nous donner le contenur de /etc/group | grep -i pamwork? Par ailleurs ton message devrait etre dans Support et non dans pause café 😉 ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 12, 2020, 11:30 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/3 "2020-11-12T23:30:38Z")
``` # cat /etc/group | grep -i pamwork pamwork:x:1002:aspdeb,pam ``` pamwork est dans le résultat de `groups pam`, mais j’avoue, c’est plus lisible ainsi 😊. Ce n’est pas le genre de chose qui va m’arrêter, alors pose café ;). ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 13, 2020, 10:51 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/4 "2020-11-13T10:51:23Z")
Bonjour, Il suffisait de rebooter 😕, L’utilisateur pam appartenant au groupe pamwok vient d’écrire un fichier dans le répertoire ForUs (root:pamwork). ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 13, 2020, 11:03 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/5 "2020-11-13T11:03:36Z")
Peut-être suffisait-il de fermer et de ré-ouvrir l’émulateur de terminal ? Idem pour tout changement du fichier .bashrc, mais là c’est logique. Les fichiers créés avec des umask différents placés dans .bashrc ont tous les même droits. Bref, il faut que je revoie les processus de lancement des différentes consoles. Merci encore. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 13, 2020, 11:24 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/6 "2020-11-13T11:24:32Z")
> [@pam547](#): > > Peut-être suffisait-il de fermer et de ré-ouvrir l’émulateur de terminal ? Je ne pense pas car les groupes sont pris en compte à l’ouverture de session. Par contre il était inutile de redémarrer le système. PS : regarde le SGID et l’umask si tu as besoin qu’un fichier créé dans ce répertoire par un utilisateur soit modifiable par les autres utilisateurs du groupe. ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 13, 2020, 11:36 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/7 "2020-11-13T11:36:10Z")
> [@PascalHambourg](#): > > PS : regarde le SGID et l’umask si tu as besoin qu’un fichier créé dans ce répertoire par un utilisateur soit modifiable par les autres utilisateurs du groupe. J’y porterai une attention très particulière lors de la série de test qui va suivre. Merci beaucoup. * * * Ce qui va être « coton », si vous permettez l’expression, c’est de mettre en place un système de journalisation pour ce répertoire 😅. ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Novembre 13, 2020, 1:27 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/8 "2020-11-13T13:27:11Z")
> [@pam547](#): > > `# cat /etc/group | grep -i pamwork` Si je peux me permettre, la syntaxe d’utilisation de grep est: `grep [options] motif fichier`, tu peux donc te simplifier la vie (et faire l’économie d’un processus) en exécutant tout simplement `grep -i pamwork /etc/group` La syntaxe `cat fichier | grep motif` est un cas typique de [useless use of cat](https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat) Voilà j’arrête de pinailler 😄 ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 9:32 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/9 "2020-11-14T09:32:19Z")
Re- Tant que « c’est encore chaud », je re-sollicite votre expertise. J’attendrai d’avoir fini le chapitre [3. Initialisation du système](file:///usr/share/debian-reference/ch03.fr.html) pour revenir vers vous 😊. D’abord l’état des lieux du sujet : > [@Sputnik93](#): > > Voilà j’arrête de pinailler 😄 Merci pour la remarque, certaines choses ne sont jamais assez répétées. C’est aussi signalé là → > `$ > `$ visualisateur > `$ visualisateur /etc/motd` > > `$ cat /etc/motd | visualisateur` > > Bien que ces 4 exemples de redirections d’interpréteur de commande affichent la même chose, le dernier exemple utilise la commande supplémentaire `cat` et gaspille des ressources sans raison. Le visualisateur se paramètre avec \< `update-alternatives --config` \> je crois. * * * > [@PascalHambourg](#): > > Je ne pense pas car les groupes sont pris en compte à l’ouverture de session. Par contre il était inutile de redémarrer le système. J’ai honte 😓, c’est écrit là → > Afin que des permissions attribuées à un groupe soient appliquées à un utilisateur particulier, il faut que cet utilisateur soit déclaré membre du groupe à l’aide de « `sudo vigr` » pour `/etc/group` ou « `sudo vigr -s` » pour `/etc/gshadow` . La nouvelle configuration du groupe n’est effective qu’après une [re]connexion de l’utilisateur (ou l’exécution de « `exec newgrp` »). * * * Et donc, pour ce qui est du partage collaboratif dans un même répertoire. J’ai joué avec le sticky bit sur le répertoire pour éviter la suppression de fichier par un membre du groupe n’étant pas le propriétaire. Mais dans ce cas, la modification du fichier par un membre du groupe n’est plus possible non-plus. Alors à quoi bon pouvoir créer des permissions en écriture pour le groupe avec ce style de fichier ? ``` pam@pammob:/home$ ls -l total 36 [...] drwxrwsr-t 2 root pamwork 4096 14 nov. 10:09 ForUs [...] pam@pammob:/home/ForUs$ ls -l total 44 -rw-rw-r-- 1 aspdeb pamwork 29 14 nov. 10:09 Acorriger [...] pam@pammob:/home/ForUs$ echo "Encore faudrait-il que j'apprenne à utiliser sed, awk, tcl ou pearl" >> Acorriger bash: Acorriger: Permission non accordée ``` Le propriétaire du répertoire (root) configure le set group ID pour que les nouveaux fichiers de ce répertoire soit du type user:pamwork. Il paramètre aussi le stiky bit pour empêcher un membre du groupe d’effacer le fichier d’un collègue. Aspdeb, crée un fichier, et change les permissions pour que le groupe puisse écrire dans ce fichier (sans l’umask pour éviter de trop compliquer). Pam peut lire le fichier, mais ne peut pas le corriger. Alors évidemment, empêcher d’effacer un fichier mais permettre de le vider est ridicule 😏. Mais pouvoir lui donner des droits d’écriture inexploitable aussi. J’ai une erreur quelque part ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 10:12 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/10 "2020-11-14T10:12:35Z")
> [@pam547](#): > > J’ai joué avec le sticky bit sur le répertoire pour éviter la suppression de fichier par un membre du groupe n’étant pas le propriétaire. Mais dans ce cas, la modification du fichier par un membre du groupe n’est plus possible non-plus. Non, le sticky bit du répertoire n’a rien à voir avec la modification des fichiers. Le droit de créer ou supprimer un fichier dépend uniquement des permissions du répertoire, alors que le droit de modifier un fichier dépend uniquement des permissions du fichier. > [@pam547](#): > > Le propriétaire du répertoire (root) configure le set group ID pour que les nouveaux fichiers de ce répertoire soit du type user:pamwork. Il paramètre aussi le stiky bit pour empêcher un membre du groupe d’effacer le fichier d’un collègue. > Aspdeb, crée un fichier, et change les permissions pour que le groupe puisse écrire dans ce fichier (sans l’umask pour éviter de trop compliquer). > Pam peut lire le fichier, mais ne peut pas le corriger. Chez moi ça marche avec les mêmes permissions. As-tu vérifié les groupes effectifs de la session de l’utilisateur pam avec la commande `id` ? Peut-il créer un fichier dans le répertoire partagé ? Les permissions Unix standard ne sont pas forcément très souples pour gérer ce genre de chose. Tu peux aussi regarder du côté des ACL POSIX qui permettent de gérer les droits plus finement. ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 10:20 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/11 "2020-11-14T10:20:58Z")
Merci infiniment pour votre attention. > [@PascalHambourg](#): > > Non, le sticky bit du répertoire n’a rien à voir avec la modification des fichiers. Le droit de créer ou supprimer un fichier dépend uniquement des permissions du répertoire, alors que le droit de modifier un fichier dépend uniquement des permissions du fichier. Pourtant dans file:///usr/share/debian-reference/ch01.fr.html#\_filesystem\_permissions > Positionner le **sticky bit** d’un répertoire empêche un fichier de ce répertoire d’être supprimé par un utilisateur qui n’est pas le propriétaire du fichier. J’analyse la seconde partie de votre message de suite. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 10:22 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/12 "2020-11-14T10:22:07Z")
> [@pam547](#): > > Positionner le **sticky bit** d’un répertoire empêche un fichier de ce répertoire d’être supprimé par un utilisateur qui n’est pas le propriétaire du fichier. En quoi est-ce contradictoire avec ce que j’ai écrit ? ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 10:24 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/13 "2020-11-14T10:24:38Z")
> [@PascalHambourg](#): > > En quoi est-ce contradictoire avec ce que j’ai écrit ? En rien, heureusement que vous êtes là pour m’aider à y voir clair. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 10:30 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/14 "2020-11-14T10:30:03Z")
Ce n’est pas mentionné, mais apparemment le sticky bit empêche aussi de renommer un fichier d’un autre utilisateur. Il serait sans doute plus précis de dire qu’il empêche toute modification de l’entrée de répertoire du fichier (suppression, déplacement, renommage). ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 10:34 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/15 "2020-11-14T10:34:42Z")
> [@PascalHambourg](#): > > Chez moi ça marche avec les mêmes permissions. As-tu vérifié les groupes effectifs de la session de l’utilisateur pam avec la commande `id` ? Peut-il créer un fichier dans le répertoire partagé ? ``` pam@pammob:/home$ id -G 1000 24 25 29 30 44 46 109 111 116 117 1002 pam@pammob:/home$ id -g 1000 root@pammob:/home# grep 1002 /etc/group pamwork:x:1002:aspdeb,pam ``` C’est donc à ce niveau qu’agirait `< vigr >` 🤨 ? * * * Oui PascaleHambourg, pam peut écrire dans /home/ForUs/ ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 10:36 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/16 "2020-11-14T10:36:15Z")
Ce serait plus lisible d’afficher les noms des groupes (`id` sans option -G ni -g) ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 10:37 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/17 "2020-11-14T10:37:50Z")
``` pam@pammob:/home$ id uid=1000(pam) gid=1000(pam) groupes=1000(pam),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev),111(bluetooth),116(lpadmin),117(scanner),1002(pamwork) ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 10:40 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/18 "2020-11-14T10:40:53Z")
Je ne vois pas ce qui cloche. Tu peux essayer de changer le groupe effectif avec `newgrp`, mais ça ne devrait pas être nécessaire. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2020, 11:18 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/20 "2020-11-14T11:18:45Z")
> [@pam547](#): > > Alors évidemment, empêcher d’effacer un fichier mais permettre de le vider est ridicule Effectivement si on donne la permission en écriture au groupe sur tous les fichiers du répertoire, le sticky bit ne sert pas à grand-chose. Mais sans le sticky bit un utilisateur qui a la permission d’écriture sur le répertoire pourrait supprimer un fichier ne lui appartenant pas indépendamment des permissions en écriture sur ce fichier. ---
**Author:** ![pam547](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pam547](https://www.debian-fr.org/u/pam547)\ **Post date:** [Novembre 14, 2020, 12:46 UTC](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286/21 "2020-11-14T12:46:17Z")
Yep, Alors, le comportement du sticky bit sur le répertoire correspond à ce qui est indiqué dans la doc, tant que root n’est pas propriétaire du répertoire --\> ``` root@pammob:/home# chown aspdeb:pamwork ForUs/ pam@pammob:/home/ForUs$ echo "Encore faudrait-il que j'apprenne à utiliser sed, awk, tcl ou pearl" >> Acorriger pam@pammob:/home/ForUs$ rm Acorriger rm: impossible de supprimer 'Acorriger': Opération non permise root@pammob:/home# chown root:pamwork ForUs/ pam@pammob:/home/ForUs$ echo "Encore faudrait-il que j'apprenne à utiliser sed, awk, tcl ou pearl" >> Acorriger bash: Acorriger: Permission non accordée ``` 🕶 [Page suivante](https://www.debian-fr.org/t/systeme-de-fichiers-droits-decriture-refuse-dans-un-repertoire-root-group-bullseye/83286.md?page=2)