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.
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é 
# 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é ;).
Bonjour,
Il suffisait de rebooter 
,
L’utilisateur pam appartenant au groupe pamwok vient d’écrire un fichier dans le répertoire ForUs (root:pamwork).
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.
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.
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 
.
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
Voilà j’arrête de pinailler 
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 :
Merci pour la remarque, certaines choses ne sont jamais assez répétées. C’est aussi signalé là -->
$ </etc/motd visualisateur
$ visualisateur </etc/motd
$ visualisateur /etc/motd
$ cat /etc/motd | visualisateurBien que ces 4 exemples de redirections d’interpréteur de commande affichent la même chose, le dernier exemple utilise la commande supplémentaire
catet gaspille des ressources sans raison.
Le visualisateur se paramètre avec < update-alternatives --config > je crois.
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/groupou «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 ?
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.
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.
Merci infiniment pour votre attention.
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.
En quoi est-ce contradictoire avec ce que j’ai écrit ?
En rien, heureusement que vous êtes là pour m’aider à y voir clair.
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).
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/
Ce serait plus lisible d’afficher les noms des groupes (id sans option -G ni -g)
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)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.
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.
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
