Salut
nitramcastel.
Ton message avait intrigué mon attention il y a quelques jours, au survol d’entrées nouvelles, , mais voilà que la vague_Mavericks a submergé l'espace de ce forum d'une déferlante de plaignants qui donnent l'impression de se presser aux portes d'un hôpital de campagne à l'heure d'une épidémie foudroyante 
. J'ai donc eu quelque peine à remonter cette foule temporelle pour aller te retrouver ainsi posté à l'écart dans le 'passé'. 'Passé' pourtant toujours 'présent' pour toi, je le suppose, de par la résilience du problème que tu évoques / 'passé' tout autant 'présent' pour moi, curieusement, de par sa résonance de question dans mon esprit, qui y a inscrit une rémanence. Je dis : 'curieusement', car je n'ai jamais utilisé de système 'serveur', non plus que je n'ai assuré de tâche administrative sur un réseau. Malgré mon inexpérience, donc, ce que je me suis figuré du problème m'a intrigué.
Je vais décrire une simulation, dont je ne sais pas si elle correspond exactement à tes attentes (si ce n’est pas le cas, vois-y un exercice du raisonnement qui aura eu le mérite de ramener ton sujet à la surface de l’actualité).
♤
Supposons que
nitrocatel ait créé dans l'espace-racine de l'OS de son
iMac un répertoire '
PARTAGE' et, dans ce répertoire '
PARTAGE', un sous-répertoire ‘
SOUS-PARTAGE' (je me limite là quant à la complexité de l'arborescence du dossier-partagé). Afin de créer le répertoire '
PARTAGE' dans l'espace-racine de l'OS,
nitrocatel qui n'est qu'un simple admin (quoique peut-être le seul, en tout cas l'aborigène de l'OS), a dû se promouvoir
sudoer en renseignant, à la création du répertoire, son mot-de-passe admin qui lui a fait emprunter l'autorité de
root (le Super Administrateur-Système). Les droits du dossier créé sont donc à l'origine :
drwxr-xr-x nitrocastel wheel PARTAGE, c'est-à-dire que seul
nitrocastel peut
écrire à l'espace contenu dans le répertoire, ce qui lui a permis de créer le sous-dossier '
SOUS-PARTAGE', avec les mêmes droits :
drwxr-xr-x nitrocastel wheel SOUS-PARTAGE. Et etc. pour tout ce que
nitrocastel crée comme arborescence de sous-dossiers dans le répertoire de départ '
PARTAGE'.
nitrocatel n'a pas nativement le choix du groupe, qui est
wheel de par l'espace-système où il crée le répertoire, et ce groupe se trouve hérité par les sous-répertoires (ex. '
SOUS-PARTAGE') qu'il crée dans ce répertoire ; par contre, grâce au statut de
sudoer qu'il a emprunté, il s'est instauré en propriétaire sur l'espace du répertoire '
PARTAGE' qu'il a créé, et donc tous les sous-répertoires qu'il y crée sont aussi sa propriété.
Pourquoi à la création d'un répertoire les permissions sont-elles drwxr-xr-x? Car, par défaut, un filtre est imposé par le Système par rapport à la référence des permissions absolues (drwxrwxrwx), qui limite la capacité d'un utilisateur (fût-il admin) à attribuer des permissions aux items qu'il crée (il s'agit du filtre u-mask, qui 'masque' d'un filtre par défaut la capacité d'un 'u_ser' à attribuer des permissions aux items qu'il crée). En ce qui concerne des dossiers, le filtre u-mask par défaut conduit un utilisateur à s'attribuer des permissions entières sur l'espace du répertoire qu'il crée, mais à les limiter à lecture + exécution pour le groupe et les autres (ce qui veut dire : possibilité de pénétrer dans l'espace du répertoire = exécuter_l'entrée + possibilité de visionner ce qui se trouve dans cet espace = lire_le_champ, mais impossibilité de modifier l'espace contenu dans le répertoire = écrire_le_champ.
♡
nitrocastel à présent veut instaurer le répertoire '
PARTAGE' et son sous-répertoire '
SOUS-PARTAGE' en dossier-partagé par des utilisateurs distants utilisant des ordinateurs distants. Supposons pour simplifier encore
1 seul utilisateur distant =
macuser utilisant un
MacBook Pro.
nitrocastel voudrait que
macuser puisse se connecter en Wi-Fi à son
iMac pour n'y avoir accès qu'au seul dossier-partagé '
PARTAGE' et par suite aux sous-répertoires qu'il contient (dans notre exemple : '
SOUS-PARTAGE'). Mais, comme a priori (par l'effet de l'
u-mask qui n'accorde que des permissions d'
entrée-lecture à tous ceux qui ne sont pas lui-même) l'invité ne pourrait rien faire d'autre que regarder, ce qui n'est pas le but du 'partage',
nitrocastel veut que les 'partageants' soient promus à des permissions d'
écriture dans l'espace du répertoire partagé et le sub-espace des sous-répertoires. Que va-t-il faire?
-
nitrocastel crée 1 autre compte sur son Mac, supposons-le intitulé «
admin», supposons avec des droits '
admin' sur l'OS (ce qui est bien généreux à première vue), et dont le mot-de-passe également est '
admin’.
- dans les
Préférences Système/Partage il coche la seule case : '
Partage de fichiers' ; à la rubrique : '
Dossiers partagés', en actionnant l'option '
+', introduit le répertoire '
PARTAGE' ; et à la rubrique ‘
Utilisateurs’, il introduit (là aussi par l'option '
+') l'utilisateur
admin comme co-usager du répertoire '
PARTAGE' avec des permissions de
lecture/écriture [NB. il pourrait, à condition d'avoir créé un groupe spécial au préalable, et avoir intronisé
admin comme membre de ce groupe, se borner à ajouter ledit groupe spécial comme co-groupe du répertoire '
PARTAGE' à côté de
wheel - mais cela est une autre histoire qui compliquerait un tantinet la procédure].
- cela fait,
nitrocastel a quitté les
Préférences Système, est allé au répertoire '
PARTAGE' à la racine de l'OS, a ouvert une fenêtre d'information, et a pu apercevoir le nouvel accédant nanti de permissions en
lecture/écriture (éventuellement pendant un laps de temps notable identifié seulement comme '
chargement en c...'
). Peu importe, l'
Accès de Contrôle d'Entrée est bien créé).
nitrocastel, après avoir déverrouillé le cadenas d'administration, a cliqué le nouvel accédant (= '
chargement en c... éventuellement) pour sélectionner l'engrenage subalterne et cliquer l'option :
Appliquer aux éléments inclus. Ce faisant, il a passé une commande récursive en mode graphique, étendant à l'arborescence des sous-répertoires les permissions du néo-accédant. Ce qui veut dire que (sous le masque de '
chargement en c...') le néo-usager
admin possède des permissions en
lecture/écriture sur l’espace du sous-répertoire '
SOUS-PARTAGE’, en sus de l’espace du répertoire ‘
PARTAGE’ dans notre exemple.
L'opération faite,
macuser a accès au répertoire '
PARTAGE' de l'
iMac de
nitrocastel en Wi-Fi en s'identifiant comme
Accédant en qualité de
admin ,
nitrocastel lui ayant fourni les identifiants de ce compte d'utilisateur de son
iMac : nom abrégé et mot-de-passe afin de lui permettre de se connecter. Et par extension de permissions d'accès, il a accès en
lecture-écriture à l'espace du sous-répertoire '
SOUS-PARTAGE'.
♧
Désormais,
macuser autant que
nitrocastel, en étant à tous les étages co-users de l'espace et des sub-espaces du répertoire partagé en permissions totales (
rwx) peuvent donc non seulement
entrer et
voir ce qui s'y trouve, mais aussi modifier l'existence de cet espace en
ajoutant ou
supprimant des éléments (
écrire).
Ce qui nous amène à la question des éléments contenus dans l'espace/sub-espace : les
fichiers. Un fichier a un double statut, selon qu'on le considère 'en amont' ou 'en aval'.
- En-amont, un fichier est un élément compris dans un espace enveloppant (celui du dossier qui le contient). De ce point de vue, ce sont les permissions liées au dossier dont l'espace contient l'élément qui déterminent ce qu'on peut faire de l'élément considéré comme 'chose opaque' = objet. Avec seulement des permissions de dossier r-x, il est possible d'entrer dans l'espace contenant l'objet et de le voir avec la possibilité additionnelle de le copier ; avec en plus la permission w, il est possible de supprimer l'objet de son espace d'appartenance (comme d'ajouter de nouveau objets).
- En-aval, un fichier est une enveloppe contenant un espace d'écriture (celui de son contenu). De ce point de vue, ce sont les permissions liées au fichier qui déterminent ce qu'on peut faire de l'espace qu'il contient non plus en qualité d'objet relevant d'un espace supérieur, mais en tant que contenant d'un espace propre. Ces permissions n'ont rien à voir avec celles appendues au dossier où il réside. Supposons par exemple un fichier dont les permissions sont en interdiction d'accès pour quiconque n'est pas le propriétaire, résidant dans un dossier où les permissions d'accès sont totales pour tous : un accédant qui n'est pas le propriétaire du fichier peut entrer dans l'espace du dossier, voir le fichier en tant qu'objet, et même le supprimer en tant qu'objet du dossier ; jamais il ne va pouvoir lire le contenu du fichier (l'ouvrir) non plus qu'éventuellement en modifier le contenu (l'écrire).
C'est ici que le filtre
u-mask risque de poser des problèmes dans une perspective de partage. En effet, à la différence du paramètre de filtrage à la création de dossiers, le filtre
u-mask imposé par le système par défaut attribue, lors de la création de fichiers, les permissions :
Bloc de code:
-rw-r--r-- moi staff fichier
Un fichier créé par un utilisateur par défaut n'est pas un fichier
exécutable (relevant d'une application), ses permissions sont donc filtrées a priori à '
absence d'exécution' pour tous. Cela posé, le 2è filtrage apposé par l'
u-mask à la possibilité de permissions absolues prise en référence est l'autorisation d'
écriture pour le seul créateur du fichier (son propriétaire), tandis que le groupe et les autres n'ont que des permissions de
lecture.
Si donc
nitrocastel crée un fichier qu'il introduit dans l'espace/sub-espace du répertoire partagé '
PARTAGE', ce fichier porte les permissions
-rw-r--r-- nitrocastel staff, et de son côté si
macuser introduit un fichier qu'il a créé dans l'espace/sub-espace du répertoire partagé '
PARTAGE', ce fichier porte par défaut les permissions
-rw-r--r-- macuser staff. Càd. que
nitrocastel et
macuser peuvent bien éditer le contenu des fichiers dont ils sont propriétaires, mais seulement lire le contenu de ceux qu'ils n'ont pas créés. Mais ils peuvent copier les fichiers qu'ils n'ont pas créés en qualité d'objets d'un espace où ils ont des droits d'écriture (l'espace du dossier contenant l'élément), ce qui les instaure en créateurs de la copie, donc en permissions :
-rw-r--r-- sur la copie qu'ils peuvent donc éditer en
écriture. À partir de quoi, ils peuvent supprimer le fichier original en tant qu'objet, et le remplacer par le fichier édité en tant que nouvel élément de l'espace du dossier. Renversement de situation : ce fichier se trouve désormais porteur de permissions qui réduisent le créateur de l'original à une seule autorisation de
lecture du contenu (car ce fichier est une copie modifiée appropriée à celui qui l'a créée). Mais le créateur du prime-original peut avoir sa revanche, puisqu'il a des permissions de dossier en
écriture. Il peut donc de son côté copier la copie modifiée, et l'éditer de son côté en devenant le créateur de ce nouvel exemplaire. S'il supprime la copie modifiée de l'espace du dossier, pour la remplacer par son nouvel exemplaire édité, il rétablit les permissions en l'état primitif : l'autre n'a plus que des droits de
lecture du contenu, aussi longtemps qu'il ne crée pas de copie.
♢
Est-il possible de modifier cette situation relative aux fichiers, afin que des droits en
lecture/écriture y soient appendus
dès le départ? La réponse la plus simple à cette question (mais qui dépend d'une discipline volontaire), est que, à chaque création de fichier et avant introduction dans le dossier partagé,
nitrocastel et
macuser passent sur leur Mac par la fenêtre d'information du
Finder et en déverrouillant le cadenas d'administration, rectifient les permissions des non-propriétaires du fichiers (staff et everyone) en les virant à
lecture & écriture. Ainsi, le futur partageant qui n'est pas le créateur du fichier a néanmoins sur lui des droits d'écriture, sans avoir besoin de passer par une copie. Mais cette rectification des permissions doit être surveillée à chaque édition du fichier - ce qui est astreignant.
Une modification automatique est possible, consistant à modifier a priori le filtre
u-mask qui s'applique aux permissions attribuées à la création d'un fichier ou d'un dossier. Pour cela, il faut affecter le processus
launchd avant que la session d'un utilisateur du Mac ne se lance avec des paramètres préfixés. Néanmoins, il serait hautement dangereux d'adresser ce paramétrage au processus_parent dans son universalité, et il bien plus recommandable de ne le lui adresser qu'en commande spécifique du paramétrage de l'activité dans la GUI d'utilisateurs. Par suite, je recommanderais ce qui suit : créer dans le répertoire-racine invisible
etc le fichier vide (qui n'y existe pas) :
launchd-user.conf par la commande suivante dans le «
Terminal» :
Bloc de code:
sudo touch /etc/launchd-user.conf
et ↩︎ (retour-chariot : presser la touche 'Enter' = 'Retour' pour activer la commande). Demande de
password car c'est une commande
sudo → taper à l'aveugle le mot-de-passe admin et ↩︎ derechef. Le fichier vide
launchd-user.conf est créé dans le répertoire
etc. Maintenant ouvrir le fichier dans «
TextEdit» par la commande :
Bloc de code:
sudo open -e etc/launchd-user.conf
(dans le délai de grâce de 5' par défaut des droits de
sudoer aucun mot-de-passe n'est requis). La fenêtre d'écriture du fichier s'ouvre dans «
TextEdit». Taper tout simplement (non plus dans le «
Terminal», mais dans la fenêtre «
TextEdit)» :
et sauvegarder le fichier édité. Re-démarrer (pour que le paramétrage soit pris en compte par le processus
launchd). Le processeur
launchd lorsqu'il est lancé par le
kernel après le chargement des bases du système BSD-UNIX, 'visite' le répertoire
etc en quête d'instructions de paramétrage relatives au lancement des superstructures de l'OS. Un fichier
launchd-user.conf va être pris en compte avant la GUI des utilisateurs, et l'instruction
umask 000 en valeurs octales signifie que tout usager du Mac qui y a une session ouverte désormais va créer des dossiers et des fichiers en permissions absolues
drwxrwxrwx et
-rw-rw-rw-. Dans le cadre de partage, tout sera donc non seulement lisible, mais éditable d'entrée. [Les permissions absolues de référence sont 777 pour les dossiers et 666 pour les fichiers en valeurs octales, qui attribuent
4 à
r,
2 à
w et
1 à
x. 777 pour un dossier =
drwxrwxrwx et 666 pour un fichier = -
rw-rw-rw- (puisque par défaut les fichiers ne sont pas des exécutables). Cela en possibilité absolue. L'
umask qui filtre ces possibilités absolues est par défaut, comme paramétrage système :
022 en valeurs octales destinées à se soustraire aux valeurs de référence absolues, soit : rien d'ôté aux permission du propriétaire,
2 d'ôté (soit
w=2, la permission d'écriture) aux permissions du groupe et des autres, ce qui donne par défaut
755 pour les dossiers et
644 pour les fichiers → à part le propriétaire qui est en
rwx pour les dossier et
rw- pour les fichiers, groupe et autres sont en
r-x pour les dossiers et en
r-- pour les fichiers. Instruire la valeur octale de l'
umask à
000 revient à neutraliser l'
umask à tous les étages pour les utilisateurs, qui désormais créeront des items en permissions d'
écriture pour groupe et tout-venant. Le fichier de paramétrage de
launchd peut à tout moment être édité en le réouvrant par la commande dans le «
Terminal» :
Bloc de code:
sudo open -e etc/launchd-user.conf
Dans le fenêtre «
TextEdit», renseigner comme valeur octale de l'
umask 022 pour revenir à la valeur par défaut (ce qui s'obtient aussi en supprimant le fichier) ;
002 pour n'accorder de permissions d'écriture qu'à des membres du groupe de référence.
Le problème est que, si
nitrocastel en session ouverte sur son iMac bénéficie de la neutralsation du filtre
u-mask,
macuser, lui, crée ses fichiers sur un Mac sur lequel le filtre
u-mask par défaut (
022) n'a pas été modifié et donc ses fichiers seront en
-rw-r--r-- (lorsque
macuser se connecte à l'
iMac de
nitrocastel avec les identifiants du compte
admin de l'
iMac, il n'en ouvre pas la session pour autant). Il faut donc que
nitrocastel ET
macuser accordent leurs violons pour rectifier la valeur octale de l'
umask sur leurs Macs respectifs à
000,et alors ils n'auront plus de problèmes d'accès total aux fichiers partagés (le reste de leur Mac étant hors d'atteinte, en cas de restriction du partage au répertoire listé) <
je garantis la validité du paramétrage par fichier launchd-user.conf dans etc, je l'utilise sur mon propre Mac et cela marche impeccablement>
♘
