Jean
J'obtiens les mêmes informations que toi avec les mêmes commandes. Donc je ne vois rien là-dedans qui fasse ressortir une différence capable de rendre compte du « paradoxe de Jean » (
E pur si muove !)...
Si je reprends l'état des lieux de mon côté : un fichier partagé
Test du Mac de
maco, qui a au départ pour
user maco , avec
toto du Mac de
toto bénéficiant d'une
ACE "toto allow write" (panneau de Partage > sélection du dossier partage
BROL > clic_secondaire > "
Appliquer les autorisations aux éléments inclus" > création d'une
ACE 0: user:toto allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity dans l'
ACL du fichier) ; une fois édité et sauvegardé en
écriture par
toto, ce fichier se retrouve avec
toto pour
user (lequel n'a plus d'
ACE du coup) => conséquence : quand
maco, l'ex-
user, tente d'
écrire au fichier qu'il a créé et qui est stocké sur le Mac de
maco, un panneau d'interdiction s'affiche, lui disant qu'il n'a pas les autorisations pour écrire au fichier, mais qu'il peut seulement écrire à un duplicata du fichier.
Le point critique dans mes expérimentations est donc le suivant :
toto a accès en
écriture au fichier partagé
Test dont l'
user est
maco grâce à l'
ACE "toto allow write" de l'
ACL du fichier. Il peut donc user de cette permission d'
écriture d'
ACE, mais, dès qu'il
sauvegarde le fichier
Test qu'il vient d'éditer, tout se passe comme si cet acte le
substituait à
maco comme
user POSIX du fichier, tout en
supprimant l'
ACE associée
"toto allow write". C'est donc comme si
sauvegarder le fichier, c'était
écrire l'ACE au fichier comme
permission POSIX, au lieu de se contenter d'en user en tant qu'
ACE.
En effet, si
toto sauvegardait le fichier simplement
de par sa permission d'ACE " toto allow write ", alors l'
user POSIX du fichier (=
maco) ne serait pas affecté, puisqu'il s'agit d'un autre registre de droits. Et là, tout « tournerait » comme il faut en terme de permission d'
écriture bilatérale.
maco écrirait continûment en tant qu'
user maco POSIX en
rw sur le fichier, et
toto écrirait continûment au même fichier en tant que
bénéficiaire d'ACL en
w ne supplantant jamais l'
user POSIX maco. Mais ce n'est pas ce qui se passe chez moi (non plus que chez
Wolf) : quand
toto sauvegarde, il
convertit en fait sa
prérogative d'ACL en
privilège d'usership POSIX sur le fichier. C'est ça qui fiche le bazar... Que
Jean soit indemne de cette facétie
ACE rw => usership POSIX rw, c'est ce que j'aimerais bien comprendre, mais que je ne parviens pas à saisir.
J'ai vérifié sur un dossier partagé entre utilisateurs d'un même OS sur son
MBP 17 (
maco et
toto encore) qu'il en va de même : dès que
toto sauvegarde, il convertit son
ACE rw => usership POSIX rw et devient l'
user du fichier. Donc ça me semble un comportement surprenant, mais itératif. Une
variable cachée =
x qui opérerait chez
Jean ? - Je ne vois que cette possibilité, mais de quoi s'agit-il ? Telle est la question....
--------------------
J'ai trouvé une nouvelle solution de contournement chemin faisant, mais qui ne fait guère avancer la copmpréhension du paradoxe par ailleurs. Je suis parti de mon idée tardive d'hier : à savoir, la possibilité d'«
ignorer les autorisations sur un volume » montant à partir d'un disque externe, comme une clé USB. La conséquence de pareille option est que l'utilisateur donc la session est ouverte au moment du montage en volume du disque externe se trouve intronisé (récursivement sur l'arborescence de fichiers du volume)
user par provision : il a donc automatiquement permissions de
lecture / écriture aux fichiers contenus sans obstacle de droits
POSIX fixés à demeure sur les fichiers (qui sont momentanément suspendus).
maco a donc attaché une clé USB au
MBP 17 de
maco, ce qui donne lieu à un volume monté
CLE. Dans ce volume,
maco a créé un dossier partagé
BROL-CLE contenant un double du fichier
Test.
maco s'est assuré que l'
ownership est bien
désactivée sur le volume en question. Cela fait, dans le panneau Partage, il a intronisé
toto comme associé au partage du dossier
BROL-CLE et appliqué aux éléments inclus. On obtient sur le fichier
Test un état de droits équivalent à celui du dossier partagé
BROL précédemment utilisé =>
-rw-r--r-- maco staff +
ACE "toto allow write" écrite par l'acte de propagation précédent.
toto se connecte au dossier
BROL-CLE comme il le faisait avant à
BROL : il
écrit au fichier
Test de part son
ACE "toto allow write" et une fois qu'il a
sauvegardé, les droits du fichier, vus de son côté, sont devenus :
-rw-r--r-- toto staff. Plus d'
ACE. Bref : exactement la même
conversion ACE rw => usership POSIX rw qui fichait le bazar précédemment.
Revenons à
maco :
maco de son côté va à l'espace du volume monté
CLE de sa clé USB, entre dans le dossier partagé
BROL-CLE et ouvre le fichier
Test. Il esquisse un acte d'
écriture et...
ça marche sans problème. Il
sauvegarde : pas davantage de problème.
maco a donc
écrit à un fichier
Test dont l'
user POSIX est
toto (sans avoir non plus d'
ACE qui le lui permette). Et si
toto de son côté réouvre le fichier
Test partagé, les droits demeurent
-rw-r--r-- toto staff dessus, donc il peut continuer à
écrire peinard sans plus d'
ACE.
Comment se fait-il donc que
maco puisse
écrire au fichier
-rw-r--r-- toto staff at: /
Volumes/CLE/BROL-CLE/Test dont il n'est pas l'
user, et sur lequel il n'a pas d'
ACE de type
"maco allow write" ? - la réponse est dans l'activation de l'option : "
disableOwnership" sur le volume monté
CLE. En effet, de par cette fonctionnalité active au montage du volume
CLE, l'
usership récursif du volume
CLE est détenu par l'
utilisateur donc la session est actuellement ouverte. Il s'ensuit, pour le fichier
Test qui nous importe ici, que : si l'
ownership fixée sur le fichier est bien toujours
-rw-r--r-- toto staff dans l'
absolu ; la désactivation de cette
ownership sur le volume monté établit momentanément les
autorisations d'usage à :
-rw-r--r-- maco staff => il y a là un surclassement (
overriding) à la volée, qui fait que
maco aura toujours un droit d'
user par provision sur les contenus du volume
CLE ; tandis que
toto, qui n'a pas accès au volume monté
CLE, mais au dossier partagé
BROL-CLE, lui, après sa première édition sauvegardée du fichier
Test, conserve son statut d'
user POSIX rw- sur le fichier
Test => il pourra donc de son côté continuer d'
écrire tant qu'il voudra.
On a donc affaire à un curieux «
renversement de statut de propriété » ici : l'
user POSIX maco, créateur du fichier partagé
Test, se trouve dépossédé de cet
ownership, pour passer à un statut d'
user par provision grâce à la désactivation des autorisations sur le volume ; tandis que le
bénéficiaire d'ACE toto, à partir de sa première
sauvegarde d'
écriture à
Test, se retrouve intronisé
user POSIX statutaire du fichier comme s'il l'avait créé.
=> il suffirait donc que
Wolf déplace son dossier partagé sur une clé USB en répétant dessus la procédure de Partage avec son collègue et j'ai tout lieu de penser que ça se passerait comme je viens de le décrire, s'il s'assure, en faisant un
⌘I sur le volume monté de sa clé, que la case tout en bas du panneau : "
Ignorer les autorisations de ce volume" est bien cochée.
--------------------
Peut-on tirer des enseignements de cette méthode de contournement au cas d'un dossier partagé résidant dans le volume de l'OS ? - Ça ne me semble pas le cas pour la raison suivante :
- dans le cas de ma clé, le volume CLE est monté pour maco, et c'est seulement le dossier inclus BROL-CLE qui se trouve monté pour toto comme un "pseudo-volume" ;
- dans le cas du dossier /Shared/BROL, pour maco, ce n'est qu'un dossier de son OS et c'est seulement pour toto qu'il a le statut de "pseudo-volume" monté (à l'instar du BROL-CLE).
Conséquence :
toto va chaque fois, à sa première édition
sauvegardée au fichier
Test de chacun des dossiers partagés (
BROL-CLE et
BROL) s'instaurer en
user du fichier. Pour ce qui est de
maco, lorsque le fichier relève du dossier
BROL-CLE du volume monté pour lui
CLE de la clé, l'
ownership étant désactivée sur ce volume, il a la «
propriété d'usage provisoire » du fichier, et peut donc y écrire ; mais lorsque le fichier relève du dossier partagé
BROL de son Mac (at:
/Shared/BROL), comme il ne s'agit pas d'un volume monté pour lui, l'
ownership n'est pas désactivée, et c'est donc
toto qui reste instauré en
user POSIX sur le fichier => conséquence :
maco ne peut
pas écrire.
.
