Vous qui entrez ici, perdez toute espérance (en la simplicité de l'Être) ...
Salut
Typhuss
La solution préconisée par
Moonwalker est un grand classique en ce qui concerne le partage en
lecture /
écriture de l'ensemble de l'espace d'un volume autre que celui de l'OS démarré, qu'on appellera ici pour l'exemple
STOCKAGE.
En effet, dans une fenêtre d'informations du
Finder ciblée sur le volume en question, cocher la case : "
Ignorer les autorisations de ce volume" produit l'effet suivant : c'est l'utilisateur dont la session est
actuellement ouverte et pour lequel le volume est
monté, qui se trouve intronisé, en mode conjoncturel, le
propriétaire de l'espace de ce volume et de tous les éléments (dossiers ou fichiers) inclus.
Supposant 2 utilisateurs de l'OS :
typhuss et
toto => lorsque
typhuss ouvre sa session, le volume
STOCKAGE monte avec
typhuss comme
propriétaire en
lecture /
écriture du volume et de tout ce qu'il contient ; inversement, si
typhuss se délogge et que
toto ouvre sa session, le volume
STOCKAGE monte avec
toto comme
propriétaire en
lecture /
écriture du volume et de tout ce qu'il contient.
=> Si tu ne recherches pas d'exclusion d'utilisateurs (parce qu'en fait n'ont été créés dans ton OS que des utilisateurs a priori autorisables à l'accès complet du volume
STOCKAGE) - alors cette méthode est de loin la plus commode.
♤
Si par contre tu voulais ne réserver qu'à 2 utilisateurs (par exemple :
typhuss &
toto) un espace de partage en
lecture et
écriture d'éléments (dossiers et fichiers), dont tout autre utilisateur de l'OS se trouverait exclu a priori, alors il est possible de mettre en place une combinaison de 2 facteurs assez croquignolette mais dont je te garantis absolument l'efficacité (et dont le caractère abstrus m'affecte - peut-être bien le seul - d'hilarité
) =>
♧
- a) modification de l'umask. L'
umask (ou "masque de filtrage de l'utilisateur") est une restriction d'autorisations d'accès appliquée a priori par le Système a tout objet logique (dossier ou fichier) créé par un utilisateur, telle que la permission d'
écriture est strictement réservée à ce créateur. En valeur octale, c'est l'
umask 022 par défaut, càd. que le Système soustrait automatiquement
022 aux permissions absolues possibles qui sont de
777 pour un dossier (
7 équivalant à :
4=lecture +
2=écriture +
1=exécution de l'entrée au répertoire - ce, en triplette : un
7 pour l'
user, un
7 pour le primary group=
staff, un
7 pour le secondary group=
everyone) et de
666 pour un fichier non exécutable (
6 équivalant à :
4=lecture +
2=écriture +
0=pas d'exécution en triplette : un
6 pour l'
user, un
6 pour le primary group=
staff, un
6 pour le secondary group=
everyone).
Les permissions absolues possibles étant donc de :
777 (
lecture /
écriture /
entrée pour l'
user, le groupe
staff et
everyone) pour les dossiers, et de
666 (
lecture /
écriture sans
exécution pour l'
user, le groupe
staff et
everyone) pour les fichiers => l'
umask restrictif
022 est donc automatiquement soustrait par le Système à la création ou édition de ces objets, ce qui donne par défaut :
755 pour les dossiers (
lecture /
écriture /
entrée pour l'
user, mais
lecture /
entrée sans
écriture pour
staff et
everyone) et
644 pour les fichiers (
lecture /
écriture sans
exécution pour l'
user, mais
lecture seule pour
staff et
everyone).
Si donc l'on veut a priori que des objets propriétés en
écriture de leur créateur, soient aussi a priori en accès d'
écriture pour les autres utilisateurs membres du groupe
staff (ayant des comptes dans l'OS) mais pas n'importe qui (
everyone comme des invités), il suffit alors de modifier la valeur défaut de l'
umask à
002 => à la création / édition d'objets d'utilisateurs dans l'OS, les dossiers seront en permissions
775 et les fichiers en permissions
664, càd. que non seulement l'auteur aura la permission d'
écriture à l'objet, mais aussi ses collègues du groupe
staff.
--------------------
Dans l'OS «
El Capitan» (qui a compliqué les choses par rapport aux OS antérieurs), cette modification de l'
umask s'opère ainsi => passer d'abord une commande dans le «
Terminal» :
Bloc de code:
sudo mkdir -m 755 /private/var/db/com.apple.xpc.launchd/config
qui crée à l'adresse :
/private/var/db/com.apple.xpc.launchd un dossier intitulé
config qui n'existe pas par défaut. Si un message retournait un : "
file exists", cela voudrait dire que le dossier
config aurait été créé manuellement par un utilisateur antérieurement et donc existerait déjà sans avoir besoin d'être créé.
Une fois le dossier
config en place, passer la commande :
Bloc de code:
sudo launchctl config user umask 002
qui va créer dans le dossier
config un fichier de préférence
user.plist comportant les paramètres :
Bloc de code:
<key>Umask</key>
<integer>2</integer>
(ce qui équivaut cryptiquement à la valeur
002).
Quelqu'un voulant restraurer l'
umask au défaut
022, devrait passer la commande :
Bloc de code:
sudo launchctl config user umask 022
qui écrit un integer
18 au fichier
user.plist. Quelqu'un voulant neutraliser totalement l'umask à
000, devrait passer la commande :
Bloc de code:
sudo launchctl config user umask 000
qui inscrit l'integer
0 au fichier
user.plist.
=> après
re-démarrage pour que le processus
launchd charge le nouveau paramètre, en cas d'
umask rectifié à
002 tout membre du groupe
staff aura donc a priori
permission d'écriture sur tout objet créé par tout autre.
♡
- b) créer dans le volume global STOCKAGE un dossier d'accès strictement réservé, que j'appellerais BROL pour l'exemple.
Une fois ce dossier créé par
typhuss, ce qui lui donne a priori les droits d'accès suivants dans une fenêtre d'info du
Finder suite à la modification à
002 de l'
umask :
Bloc de code:
typhuss : lecture et écriture
staff : lecture et écriture
everyone : lecture seule
tu passes une commande qui va strictement réserver l'accès basique au seul propriétaire
typhuss :
Bloc de code:
sudo chmod 700 /Volumes/STOCKAGE/BROL
ce qui va donner l'état de droits suivant dans une fenêtre d'infos du
Finder ciblé sur le dossier
BROL :
Bloc de code:
typhuss : lecture et écriture
everyone : accès interdit
Il te reste à déverrouiller le cadenas d'administration de la fenêtre, à presser le bouton
+ et à ajouter
toto en
lecture et écriture, ce qui constitue une
ACE dans l'
ACL du dossier : une "
Entrée de Contrôle d'Accès" spéciale dans la "
Liste de Contrôle d'Accès" de cet élément qu'est le dossier. Tu as donc dans une fenêtre d'infos du
Finder les droits suivants sur le dossier
BROL :
Bloc de code:
toto : lecture et écriture
typhuss : lecture et écriture
everyone : accès interdit
[NB. le bénéficiaire d'une
ACE = autorisation supplémentaire est toujours affiché en tête =
toto, suivi par l'
user en titre =
typhuss].
=> on a donc, dans l'espace du volume
STOCKAGE un dossier
BROL réservé en
entrée,
lecture et
écriture aux 2 seuls utilisateurs :
typhuss &
toto, à l"exclusion de quiconque d'autre.
Mais, de par l'
umask 002, tout objet créé par
typhuss ou par
toto en-dehors de ce dossier et
déplacé en lui après coup, aussi bien que tout objet créé (ou édité) par
typhuss ou par
toto dans l'espace de ce dossier => sera toujours a priori en autorisation d'
écriture pour l'autre de part l'
umask 002 - mais pour l'autre seul, puisque l'accès à l'espace du dossier
BROL n'est autorisé qu'aux 2 accédants :
typhuss (son
user propriétaire), et
toto (son co-propriétaire en vertu de l'
ACE de l'
ACL du dossier).
♢
Le caractère désopilant (pour moi seul - présumablement) de ce procédé est qu'il combine de manière paradoxale un «
élargissement » de droits (l'extension de l'
umask à la valeur
002) et un «
rétrécissement » de droits (la réservation du dossier
BROL à deux accédants seuls :
typhuss &
toto).
Tout le monde peut donc
théoriquement lire,
écrire (et
entrer) à ce que créent
typhuss aussi bien que
toto, sauf que ce laxisme formel est
vide de bénéfices pour les autres, puisque tous les objets créés par
typhuss ou
toto dans les sous-dossiers de leur dossier de compte personnel sont en accès réservés à chacun d'eux seul, et que tous les objets créés par
typhuss ou
toto dans le dossier de partage
BROL du volume
STOCKAGE ne sont en accès qu'à eux deux seuls.