super
Tu veux dire que
- avec sticky bit + propriétaire root sur le répertoire = impossible de modifier un fichier d’un autre utilisateur
- sans sticky bit ou propriétaire non root sur le répertoire = possible de modifier un fichier d’un autre utilisateur
?
Je suis extrêmement surpris car je ne vois pas en quoi le sticky bit ou le propriétaire d’un répertoire peuvent influer sur les permissions effectives des fichiers qu’il « contient ». D’ailleurs je suis incapable de reproduire ce comportement. Sur ma machine, le droit de modifier un fichier ne dépend que des permissions du fichier lui-même, pas du répertoire.
Au passage, il y a un inconvénient à faire d’un des membres du groupe le propriétaire du répertoire : il peut supprimer n’importe quel fichier malgré le sticky bit.
Ce que j’ai voulu dire, c’est seulement le premier point:
- Avec sticky bit + propriétaire root sur le répertoire = impossible de modifier un fichier d’un autre utilisateur
Oui, l’idée de devoir créer un « utilisateur système » (ou virtuel) pour être propriétaire du répertoire partagé m’a traversé l’esprit.
Le second point est son complément logique, donc s’il n’est pas vrai alors le premier point n’est pas valide.
Hum, 
- sans sticky bit ou propriétaire non root sur le répertoire = possible de modifier un fichier d’un autre utilisateur
Une configuration classique avec les droits de lectures, d’écritures, et d’exécutions, sur le propriétaire, le groupe et les autres. Je n’ai rien constaté de « bizarre » à ce niveau.
Je viens de me rendre compte que tu as marqué « bullseye » dans le titre. J’ai fait mes tests avec buster et le noyau 4.19. Quel noyau utilises-tu ?
pam@pammob:~$ uname -a
Linux pammob 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3 (2019-09-02) x86_64 GNU/Linux
J’ai dû faire un downgrade du kernel.
Un noyau 4.9 de stretch/oldstable sur bullseye/testing ? C’est un sacré downgrade.
J’ai testé avec stretch + dernier noyau 4.9.0-14 (ne n’ai plus le 4.9.0-11, trop vieux) j’observe le même comportement qu’avec buster + dernier noyau 4.19 : la combinaison sticky bit + propriétaire root du répertoire n’empêche pas d’écrire dans un fichier appartenant à un autre utilisateur. Idem avec jessie + dernier noyau 3.16.
Je me demande ce que ton système a de particulier pour avoir un comportement différent. A ma connaissance cela ne dépend que du noyau, c’est lui seul qui applique les permissions. Tu pourrais essayer avec un autre système ?
Vous me conseillez de mettre quoi sur la clé USB pour lancer une live session et faire ces tests ?
Je n’ai jamais utilisé de système live, mais je suppose que n’importe quelle image Debian live stable devrait faire l’affaire.
Pas d’autre ordinateur avec Linux sous la main ?
J’ai qu’un seul PC sous la main.
Je reviens vers vous dès que j’ai fait les tests avec un noyau plus récent. (Peut-être que demain, et si la chose m’est possible.)
La chose ne m’est pas possible pour le moment. 
Je ferai l’expérience à l’occasion sur une autre plateforme, d’ici une quinzaine de jours certainement. 
Bonsoir
pam@pammob:/home/ForUs$ uname -a
Linux pammob 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
Finalement avec la même plateforme et un autre noyau les droits sont redevenus les mêmes quelques soit le propriétaire (root et user) du dossier en question.
Merci beaucoup.
Merci du retour. Ça voudrait dire qu’il y a une incompatibilité entre le noyau 4.9 de stretch et l’userland de bullseye. Très bizarre quand même.