10.11 El Capitan Permissions des nouveaux éléments entre utilisateurs

Typhuss

Membre confirmé
1 Février 2016
38
0
Bonjour,

sur une partition de mon disque interne (Mac OS étendu - sensible à la casse, journalisé) qui sert d'espace de stockage, plusieurs utilisateurs sont en "lecture et écriture".
Permissions du disque : Capture d’écran 2016-05-16 HD.webp
Permissions d'un dossier : Capture d’écran 2016-05-16.webp

Mon souci vient lorsque je crée un dossier ou un fichier sur le disque, les autres utilisateurs ne peuvent pas le lire (ni écrire!), et n'accèdent pas aux nouveaux dossiers.
Je dois sans cesse refaire Cmd+I : Appliquer aux éléments inclus (après dé-cadenassage)

Ca ne me faisait pas ça sous Snow, et je n'ai pas trouvé d'explications et de méthode pour que les nouveaux éléments soient nativement en lecture et écriture en héritant des propriétés parentes.
Merci d'avance.
 
Et le masque dit : proprio (toi) lecture et écriture ; staff lecture seulement ; everyone lecture seulement
le masque actuel ne dit pas ça justement, il dit bien everyone : lecture et écriture. Et le but c'est que seuls certains utilisateurs soient en lecture écriture, pas nécessairement tous.
cocher : Ignorer les autorisations de ce volume
Ca ne me semble donc pas être une bonne solution de décocher pour l'ensemble du volume.

je voudrais qu'un nouvel élément hérite des propriétés du parent, et donc qu'un autre utilisateur autorisé à "voir et écrire dans" un dossier, voit (et puisse écrire) également les nouveaux éléments de ce dossier, voire des sous-dossiers, etc...
De manière similaire, un dossier (ou un fichier) créé par cet autre utilisateur autorisé est "bloqué" pour moi...
 
Vous qui entrez ici, perdez toute espérance (en la simplicité de l'Être) ...

361608_original.png

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é
361608_original.png
) =>


- 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.

367024_original.gif
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Typhuss
Merci macomaniac pour ces explications ! (toujours très techniques, mais ô combien intéressantes et riches d'enseignements)
et content si j'ai pu (encore ?!) soulever un sujet atypique.
Dans l'OS «El Capitan» (qui a compliqué les choses par rapport aux OS antérieurs)
est-ce que je fabule ou bien ce problème n'existe pas sous Snow ?
 
Salut encore Typhuss

La phrase de mon message que tu as citée :
macomaniac a dit:
Dans l'OS «El Capitan» (qui a compliqué les choses par rapport aux OS antérieurs)
se rapportait, dans son contexte, à la procédure permettant de modifier la valeur de l'umask, ou masque de filtrage de l'utilisateur.

En effet, dans les OS antérieurs à «El Capitan», point n'était besoin de créer un dossier config at: /private/var/db/com.apple.xpc.launchd, puis de passer une commande dans le «Terminal» de type :
Bloc de code:
sudo launchctl config user umask 022
(par exemple) afin d'y créer un fichier user.plist intégrant le paramètre de l'umask choisi dans une syntaxe typique de fichier .plist articulant une clé comportant le paramètre et une chaîne comportant la valeur associée de type :
Bloc de code:
<key>Umask</key>
    <integer>2</integer>
(par exemple).

Non : les choses étaient plus simples, en ce qu'il suffisait de créer dans le dossier-Système : /private/etc un fichier launchd-user.conf (dont le titre signifiait : configuration d'utilisateur à prendre en charge par le processus launchd) et dans ce fichier à écrire tout bêtement (avec un éditeur de fichier-Système comme «TextWrangler») :
Bloc de code:
umask 002
et le tour était joué : au re-démarrage, le processus parent launchd chargeait la nouvelle valeur de l'umask, et tout utilisateur créait des objets pour lesquels la permission d'écriture était accordée au groupe staff en plus de lui-même.

Comme tu vois : pas de syntaxe complexe de type fichier .plist, il suffisait de griffonner directement l'intitulé du paramètre et sa valeur et launchd, avec une obligeance fort civile, se faisait un devoir de charger cette préférence d'utilisateur.

[Le verrouillage toujours plus prononcé du fonctionnement du Système, dans les versions successives d'OS X, me désappointe, en ce qu'il faut passer par des procédés toujours plus complexes pour parvenir aux mêmes résultats qu'antérieurement. Ce qui fait regretter la simplicité plus grande des versions antérieures.]


Mais lorsque tu as écrit :
macomaniac a dit:
Dans l'OS «El Capitan» (qui a compliqué les choses par rapport aux OS antérieurs)
est-ce que je fabule ou bien ce problème n'existe pas sous Snow ?

j'ai bien compris que tu visais autre chose que la manière de modifier la valeur de l'umask - qui est, je l'admets, un point de détail abscons qu'un utilisateur est en droit d'ignorer sans pour autant se trouver engoncé dans son expérience d'utilisateur.

Oui : j'ai bien compris que tu pensais à la fonctionnalité permettant, dans OS X, de "Partager" un dossier choisi entre plusieurs utilisateurs préférentiels.

Tu as dû t'étonner de la relative complexité de la « solution » que je te proposais (umask 002 + dossier réservé) et du fait que je n'évoquais pas cette fonctionnalité du "Partage". Peut-être pas tant que cela, au fond, car tu as dû tenter d'y avoir recours dans ton nouvel OS «El Capitan» avec un résultat décevant. Si je n'ai pas évoqué cette fonctionnalité du Partage dans «El Capitan», c'est que ça me paraît une foirade complète, comme j'en avais attesté dans ce fil bien abstrus : ☞Partage de Fichier en Écriture☜ après de nombreuses expérimentations où je n'ai jamais pu répéter pour mon propre compte la manœuvre que Jean attestait réussie pour de son côté.

Comme le SSD de mon MacBook Pro 17" Late_2011 est multi-partitionné et peut démarrer aussi bien «El Capitan 10.11.5» que «Snow Léopard 10.6.8», et comme il comporte aussi une partition de simple stockage en accès ouvert intitulée Reserve (volume concernant lequel la case : "Ignorer les autorisations de ce volume" n'est pas cochée) => j'ai donc fait l'expérience suivante ce matin, pour laquelle j'ai décidé de n'utiliser que les outils graphiques du Finder =>

- a) expérience dans «El Capitan». L'umask est à la valeur default 022. Y existent 2 comptes d'utilisateurs : admin = maco et standard = toto.

Dans la session maco, je crée dans Reserve un dossier BROL. J'ouvre une fenêtre d'information du Finder dessus, et j'ai les droits : maco = lecture & écriture ; staff = lecture seule ; everyone = lecture seule.

Je coche la case : "Partage". Je déverrouille le cadenas d'administration, et : avec le bouton -, je supprime le groupe staff des accédants autorisés ; avec l'onglet des permissions, je vire everyone à accès interdit ; enfin, avec le bouton +, j'ajoute toto comme accédant, et avec l'onglet de permissions, je le vire à lecture & écriture sur le dossier => j'ai donc un dossier partagé, réservé strictement à 2 accédants : maco = user (droits basiques ou POSIX) et toto = co-user (droits supplémentaire d'ACL).

Toujours dans la session maco, je crée avec «TextEdit» un fichier intitulé maco.txt dans BROL, dans lequel je gribouille une ligne. Ce fichier, vu de la session maco, a pour droits : maco = lecture & écriture ; staff + everyone = lecture seule.

Je me délogge de la session maco et je passe en session toto. toto peut entrer dans le dossier partagé BROL sans problème, et ouvrir en lecture le fichier maco.txt. Mais à la moindre tentative d'écriture, un panneau se démasque disant que toto n'est pas le propriétaire du fichier et ne peut donc le modifier. Une fenêtre d'info du Finder montre en effet les droits : maco = lecture et écriture ; staff et everyone = lecture seule.

En session toto, je crée un fichier toto.txt dans BROL dans lequel je gribouille une ligne. Les droits sont : toto = lecture & écriture ; staff et everyone = lecture seule. Je me délogge de la session toto et je me logge dans la session maco => même blocage que précédemment : maco peut lire le fichier toto.txt de BROL, mais pas y écrire, car il n'est pas son propriétaire. Les droits sont strictement : toto = lecture & écriture ; staff et everyone = lecture seule.



- b) expérience dans «Snow Léopard». L'umask est à la valeur default 022. Y existent 2 comptes d'utilisateurs : admin = maco et standard = toto. J'ai supprimé l'ancien dossier BROL de Reserve.

Dans la session maco, je crée dans Reserve un dossier BROL. J'ouvre une fenêtre d'information du Finder dessus, et j'ai les droits : maco = lecture & écriture ; staff = lecture seule ; everyone = lecture seule.

Je coche la case : "Partage". Je déverrouille le cadenas d'administration, et : avec le bouton -, je supprime le groupe staff des accédants autorisés ; avec l'onglet des permissions, je vire everyone à accès interdit ; enfin, avec le bouton +, j'ajoute toto comme accédant, et avec l'onglet de permissions, je le vire à lecture & écriture sur le dossier => j'ai donc un dossier partagé, réservé strictement à 2 accédants : maco = user (droits basiques ou POSIX) et toto = co-user (droits supplémentaire d'ACL).

Toujours dans la session maco, je crée avec «TextEdit» un fichier intitulé maco.txt dans BROL, dans lequel je gribouille une ligne. Ce fichier, vu de la session maco, a pour droits : maco = lecture & écriture ; staff + everyone = lecture seule.

Je me délogge de la session maco et je passe en session toto. toto peut entrer dans le dossier partagé BROL sans problème, et ouvrir en lecture le fichier maco.txt. Mais toto peut également directement écrire au fichier maco.txt et sauvegarder son écriture. Car ? Car une fenêtre d'info du Finder révèle les droits suivants : toto = lecture & écriture ; staff et everyone : lecture seule.

En session toto, je crée un fichier toto.txt dans BROL dans lequel je gribouille une ligne. Les droits sont : toto = lecture & écriture ; staff et everyone = lecture seule. Je me délogge de la session toto et je me logge dans la session maco => : maco peut lire le fichier toto.txt de BROL, et il peut aussi y écrire et sauvegarder son édition. Car ? Car les droits sur le fichier toto.txt, vus de la session maco, sont : maco = lecture & écriture ; staff et everyone = lecture seule.


=> Il est temps de prendre un peu de champ par rapport à tous ces détails exemplaires :

- dans «Snow Léopard» : la fonction de "Partage" d'un dossier entre 2 utilisateurs, engendre un effet strictement comparable à celui produit par la fonction "Ignorer les autorisations du volume" sur un volume indépendant de celui de l'OS démarré. À savoir : l'user (propriétaire) reconnu en titre de tout élément recelé dans le dossier partagé varie en fonction de la session qui est ouverte, avec les permissions de lecture & écriture associées à l'user. Ce qui permet une possibilité d'écriture alternative à tout élément créé par quiconque est admis à l'espace de partage, étant donné que l'utilisateur ouvrant sa session est conjoncturellement reconnu l'user en lecture & écriture de tous les contenus du dossier partagé.

- dans «El Capitan» : la fonction de "Partage" échoue à maintenir cet équivalent de la fonction "Ignorer les autorisations du volume" à l'échelle de l'espace du dossier partagé, en ce que l'user d'un élément créé dans le dossier partagé ne varie pas en fonction de la session ouverte, mais reste en mode fixe celui qui a créé l'objet au départ. Il s'ensuit qu'à partir de sa session, tout utilisateur qui n'a pas créé un objet n'y a accès qu'en tant que membre de staff ou de everyone : càd. en lecture seule. C'est exactement que qui s'était trouvé avéré dans le fil que j'ai cité par Wolf autant que par moi-même. Je conclus à une énième foirade de l'OS «El Capitan», comparable à la bourde (toujours pas corrigée) qui empêche les sauvegardes TimeMachine d'être démarrables.


Cet examen me conduit à me poser une question (que je n'ai pas pour l'instant scrutée) : quel procédé logique exact permet à la fonctionnalité de "Partage" dans l'OS «Snow Léopard» (je n'ai pas vérifié dans les intercalaires de 10.7 à 10.10) d'imiter la fonctionnalité "Ignorer les autorisation d'un volume" ? Car, connaissant ce procédé capable de s'exécuter validement dans tel OS, il serait sans doute aisé d'apprécier les raisons qui le font planter dans «El Capitan» (voire de le corriger) : bourde interne d'instruction d'un fichier ? Fichier d'instruction désormais plus pris en compte en tant que tel, comme le fichier launchd-user.conf évoqué en début de message, et qui devrait être être recréé en mode différent ? Abandon carrément de la fonctionnalité (ce qui serait énorme) ?

 
Dernière édition par un modérateur: