n'en est pas le propriétaire, et possibilité d'écrire seulement à un duplicata du fichier].
Voici mon descriptif : je ne me suis pas embêté à expérimenter entre 2 Macs, j'ai (en tant que
(= le dossier Partagé des Utilisateurs : càd. un dossier destiné au partage entre utilisateurs d'un même OS). Dans ce dossier, j'ai créé un fichier
. Ce fichier a pour droits de départ (
.
. Que se passe-t-il à présent si
. Privilège d'écriture redoublée par l'
.
. Car ? Car les droits sont actuellement
). C'est donc simplement en tant que membre du groupe principal
. Mais comme ni
, et n'a accès qu'au mode duplication de fichier => le fichier dupliqué sera alors sa propriété, et il pourra ensuite opérer un remplacement du fichier
. L'
au fichier dans sa session, mais dès qu'il sauvegardera son écriture, on aura donc derechef un état de droits modifié :
dans sa session va donc être de nouveau coincé, car non-propriétaire du fichier
qu'il faudrait répéter sur tout nouveau fichier créé - comme il faut le faire d'ailleurs en ce qui concerne l'
- a) la solution par un cron => un service temporalisé qui, toutes les 5 minutes (disons) rétablirait récursivement (par un
chown) sur le dossier partagé
BROL la propriété d'
user à
macomaniac (ce qui n'oblitèrerait pas l'
ACL "toto allow write" mais rétablirait périodiquement
macomaniac comme
user de
Test). Ce type de solution marche, mais (personnellement) je la trouve assez « bestiale », car c'est une solution de « rattrapage en aval » récurrent (
user =>
macomaniac) d'une dégradation de droits tout aussi récurrente en amont (
user =>
toto). Ce type de « rattrapage temporel » me paraît une solution « laide » (intellectuellement parlant), quoique (j'ai testé) elle marche, bien sûr...
- b)
la solution par l'umask => cette solution a toujours eu ma faveur (intellectuelle), car c'est une solution par l'amont (établissement à l'ouverture par une action de
launchd). Petit topo explicatif : l'
umask est une abrévation pour
user_mask (masque d'utilisateur). Il s'agit d'une condition restrictive, chargée par le processus
launchd au déploiement du Système (donc avant toute ouverture de session d'utilisateur), qui soustrait a priori par défaut la valeur octale
022 aux permissions des dossiers et des fichiers créés par tout utilisateur de l'OS par une application quelconque. Sur un absolu possible de
777 pour un dossier (
drwxrwxrwx user staff everyone), on obtient donc le default a priori
755 (
drwxr-xr-x user staff everyone) ; et sur un absolu de
666 pour un fichier non exécutable (
-rw-rw-rw- user staff everyone), on obtient le default a priori
644 (
-rw-r--r-- user staff everyone).
Il suffit donc de modifier la valeur default
022 de l'
umask en
002 et en conséquence le processus
launchd conditionnera a priori toute création d'utilisateur de dossier à avoir les permissions
775 (
drwxrwxr-x user staff everyone) et toute création de fichier non exécutable à avoir les permissions
664 (
-rw-rw-r-- user staff everyone). Vous voyez en quoi c'est une solution ? Tout membre du groupe
staff aura a priori une permission
POSIX d'
écriture sur tout fichier créé par tout utilisateur (je néglige ici les dossiers). Si je reprends mon descriptif premier : le fichier
Test au départ serait donc en
664 macomaniac staff everyone => pas besoin d'accorder une
ACL à
toto, car en tant que membre de
staff il a a priori la permission d'écrire au fichier dans sa session. Que va-t-il se passer quand il enregistrera ? Le fichier
Test va être viré à :
664 toto staff everyone. Lorsque
macomaniac va l'ouvrir dans sa session, en tant que membre de
staff en permission d'
écriture, il va pouvoir
écrire au fichier directement, et lorsqu'il enregistrera, le fichier sera viré à :
664 macomaniac staff everyone. Grâce au groupe
staff en permission d'
écriture, alternativement les
users qui en sont membres en tant qu'ayant comptes (dans cet OS ou dans celui d'un autre Mac, de par l'identité nominale de groupe = «
staff ») ont une permission directe d'
écriture => peu importe alors qui est provisoirement le propriétaire du fichier, en tant qu'
user venant juste de l'enregistrer à son propre nom.
Dans les version d'
OS X antérieures à «
Yosemite 10.10», il était possible de passer à
launchd la valeur qu'on voulait pour l'
umask en créant simplement un fichier
launchd-user.conf at:
/private/etc et en renseignant dedans uniquement :
ou
nnn pouvait être :
022,
002,
000 selon qu'on voulait propager la permission d'
écriture à la création de dossier/fichier d'utilisateur à l'
user seul, à
staff en surcroît ou carrément à
everyone. Apple vissant de plus en plus le fonctionnement du Système d'
OS X, ce procédé commode n'est plus honoré :
launchd ne charge plus aucune valeur renseignée dans un fichier
/private/etc/launchd-user.conf (snif !).
Qu'à cela ne tienne : voici l'alternative valide dans «
Yosemite 10.10» & «
El Capitan 10.11» => il suffit de passer une commande de la forme suivante dans le «
Terminal» :
Bloc de code:
sudo launchctl config user umask nnn
où
nnn est la valeur de l'
umask choisie pour modifier le default
022. Si l'on veut propager a priori à la création d'objets d'utilisateur (dossier/fichier) la permission d'
écriture w à
staff, alors passer la commande :
Bloc de code:
sudo launchctl config user umask 002
(avec authentification par le mot-de-passe
admin à l'aveugle à la demande de
password). Petit
caveat : l'utilitaire
launchctl est appelé pour écrire à l'adresse suivante :
/private/var/db/com.apple.xpc.launchd/config un fichier
user.plist. Si le dossier
config ne pré-existe pas dans
/private/var/db/com.apple.xpc.launchd, le message d'erreur suivant va s'afficher dans le «
Terminal» :
Bloc de code:
"Could not write configuration: No such file or Directory"
=> si tel était le cas, commencer par créer ce dossier
config par la commande :
Bloc de code:
sudo mkdir -m 755 /private/var/db/com.apple.xpc.launchd/config
et ensuite répéter la commande :
Bloc de code:
sudo launchctl config user umask 002
qui devrait passer comme une lettre à la boîte => un avertissement va s'afficher dans le «
Terminal» intimant de
re-démarrer le Mac, pour que le fichier
user.plist soit pris en compte, ce qui est logique, puisqu'il est destiné à être lu par
launchd au chargement du Système (NB. les valeurs écrites dans le fichier
user.plist ne correspondent plus aux
022,
002,
000 du fichier classique
launchd-user.conf => la commande avec la valeur
000 donne un integer
0 ; la commande avec la valeur
002 donne un integer
2 ; la commande avec la valeur default
022 donne un integer
18).
Après re-démarrage, toute création d'objet de la part de l'utilisateur se servant de quelque application que ce soit (traitement de texte par exemple ou
Finder...) donnera lieu à une permission d'
écriture supplémentaire pour
staff sur ces objets et il n'y aura plus de problèmes lors d'un partage de fichiers en ce qui concerne la permission d'
écriture (pour autant, bien sûr, qu'on ait affaire comme ici à un partage entre utilisateurs ayant-comptes utilisant
OSX, donc membres de
staff a priori).
[point 5 : possibilité d'écrire en tant qu'utilisateur = 
