dossier partagé entres utilisateurs "sans autorisations"

[joncrasi]

Bonjour,

Est-il possible de d'avoir un dossier partagé entre tous les utilisateurs d'un mac qui fonctionnerait un peu comme une clé usb, c'est à dire sans autorisations ? Quand un utilisateur déplacerait un fichier dans ce dossier partagé, tous le monde pourrait le modifier, déplacer supprimer sans avoir à rentrer de mot de passe, et quand un utilisateur le déplacerait dans ses dossier il lui appartiendrait dorénavant.

Merci

 

[subsole]

Bonjour,

Est-il possible de d'avoir un dossier partagé entre tous les utilisateurs d'un mac qui fonctionnerait un peu comme une clé usb, c'est à dire sans autorisations ? Quand un utilisateur déplacerait un fichier dans ce dossier partagé, tous le monde pourrait le modifier, déplacer supprimer sans avoir à rentrer de mot de passe, et quand un utilisateur le déplacerait dans ses dossier il lui appartiendrait dorénavant.

Merci

Bonjour
Ça, c'est le dossier Public de chaque utilisateur, non ?

 

[joncrasi]

Ça, c'est le dossier Public de chaque utilisateur.

Je viens de faire l'essai, ça me demande un mot de passe... loin d'être aussi simple qu'une clé usb

 

[subsole]

Je viens de faire l'essai, ça me demande un mot de passe... loin d'être aussi simple qu'une clé usb

Désolé

Dans il faut créer un dossier avec les droits lecture/écriture pour tous ou modifier les droits du dossier Public.

 

[joncrasi]

Dans il faut créer un dossier avec les droits lecture/écriture pour tous ou modifier les droits du dossier Public.

Mais dans ce cas le propriétaire reste toujours celui d'origine si je me trompe pas.

 

[Aliboron]

Tu peux aussi ajouter un volume dans la partition du disque dur (ou d'un des disques durs, le cas échéant) qui sera donc tout à fait comparable à une clé USB dans le fonctionnement...

 

[joncrasi]

Tu peux aussi ajouter un volume dans la partition du disque dur (ou d'un des disques durs, le cas échéant) qui sera donc tout à fait comparable à une clé USB dans le fonctionnement...

bonne idée, je crois que je vais faire ça pour le moment merci

 

[zeltron54]

j'utilise le dossier "partagé" qui est dans le dossier "utilisateurs" depuis toutes mes sessions sans demande de mot de passe ?
Pas le dossier public de chaque utilisateurs !

 

[subsole]

j'utilise le dossier "partagé" qui est dans le dossier "utilisateurs" depuis toutes mes sessions sans demande de mot de passe ?
Pas le dossier public de chaque utilisateurs !

Avec les changements de droits le nouveau dossier que je proposais ça revient au même.
Mais, tu as entièrement raison, puisque le dossier existe déjà sous la forme du dossier Partagé !

 

[Anonyme]

bonne idée, je crois que je vais faire ça pour le moment merci

Il sera nécessaire de cocher cette case, sinon le comportement sera identique à ce qu'il est dans le dossier Partagé (impossible de modifier un document sans le dupliquer au préalable pour devenir le propriétaire de la copie).

 

[Membre supprimé 1060554]

Je m'immisce dans ce fil en qualité d'épigone décomplexé, parce que, si intempestive que soit mon intervention, la question soulevée par joncrasi (touchant les permissions sur un espace de partage multi-utilisateurs) m'intéresse depuis belle lurette - et l'occasion n'est-elle pas toujours "belle' quand on invoque la "lurette" (pour ne pas dire : la "turlurette")?

Le situation varie, en effet, selon que l'espace de partage en question est celui d'un Volume distinct de celui de l'OS, ou celui d'un Dossier localisé dans le volume même de l'OS.

- 1° S'il s'agit d'un Volume distinct de celui de l'OS (comme proposé par Bernard aka Aliboron) - qui peut être celui d'une clé USB, d'un DDE, d'une carte-mémoire, voire d'une partition du disque du Mac ; alors le procédé indiqué par Renaud fait merveille : cocher dans une fenêtre d'information du Finder l'option : Ignorer les autorisations de ce volume. En effet, cette option graphique équivaut à passer la commande :

sudo diskutil disableOwnership /dev/disk--s--

qui manipule le fichier base-de-données : /var/db/volinfo.database en affectant à l'identifiant numérique du volume désigné une valeur : 0000000 à la place de 0000001 --> en conséquence de quoi, le daemon : diskarbitrationd en fin de démarrage du Mac lit cette valeur du fichier volinfo.database, ce qui opère le montage du volume correspondant de telle manière que l'identité du propriétaire (= user) et du groupe (= group) apparaisse établie comme celle de l'utilisateur dont la session est ouverte avec le groupe qui lui correspond, et non pas comme celle d'un propriétaire et d'un groupe attachés intrinsèquement au disque. Cette "appropriation à la volée" de l'espace du volume monté s'applique récursivement aux éléments qu'il contient en établissant une "appropriation à la volée" des fichiers et des dossiers localisés sur ce volume.

☞ la solution au problème ("alternance des propriétés" - et donc des permissions de lecture/écriture/exécution afférantes au propriétaire - en fonction de la session active) est donc particulièrement élégante et commode.

♤​

- 2° s'il s'agit d'un d'un Dossier relevant du volume même de l'OS, par contre, alors la situation est beaucoup plus alambiquée. Imaginons l'utilisateur admin : toto qui veut partager l'espace d'un Dossier avec un autre utilisateur admin : bibi. Pour ce faire, en suivant la suggestion de zeltron, il décide d'utiliser le répertoire dédié dans le Système : /Shared\ Items («Éléments Partagés») en y créant un sous-dossier intitulé : PARTAGE destiné à servir d'espace de partage spécifique pour lui et pour bibi (je laisse de côté l'exclusion d'autres utilisateurs éventuels, ce qui demanderait de créer un groupe spécifique toto + bibi qui en aurait l'exclusivité. Je suppose pour faire simple qu'il n'y a que 2 utilisateurs du Mac : toto & bibi, tous les deux admin).

Le problème est que toto n'a pas pris en compte le facteur de l'umask ("masque de l'utilisateur" = filtre des permissions) qui est une valeur de 022 par défaut dans OS X qui se soustrait a priori au démarrage du Mac de la valeur octale absolue possible des objets de l'OS <ou r(lire)= 4 ; w(écrire) = 2 ; x(exécuter) = 1 - ce pour chacun des accédants à l'objet : user + group + other> : soit 666 en règle générale pour les fichiers non exécutables (r=4 + w=2 + x=0 en triplet) et 777 pour les dossiers (r=4 + w=2 + x=1 en triplet) --> 666 (maximum théorique) - 022 (umask par défaut) = 644 pour les fichiers non exécutables et 777 (maximum théorique) - 022 (umask par défaut) = 755 pour les dossiers. Ce qui veut dire qu'à la création d'un dossier ou d'un fichier où que ce soit, l'utilisateur-créateur seul possède le droit d'écriture (w =2) sur les objets qu'il crée.

- a) Par conséquent, le dossier PARTAGE créé par l'admin : toto dans le répertoire /Shared\ Items, suite à l'application automatique de l'umask : 022 va être en permissions : 755 (permission d'écriture : w=2 pour l'owner seul = son créateur), ce qui va compliquer a priori la tâche pour l'autre admin : bibi --> en effet, bibi ayant nonobstant la permission executive (x=1) ce qui l'autorise à exécuter l'entrée au dossier PARTAGE (= "browser" son contenu, de manière à pouvoir le lire : r=4), il doit pouvoir forcer la permission d'écriture : w=2 qui ne lui est pas attribuée d'entrée à l'espace du dossier PARTAGE à coups d'authentifications par son mot--de-passe admin, de manière à pouvoir affecter l'existence des éléments contenus : ajouter un fichier / supprimer un fichier. Ce qui est restrictif en pratique.

Comme évoqué alors par subsole, il suffit de passer une commande simple sur le dossier PARTAGE créé par toto afin d'étendre ses permissions de 755 au départ en valeur octale - soit drwxr-xr-x toto staff - à 777 - soit : drwxrwxrwx toto staff - (ce par la commande : sudo chmod 777 /Shared\ Items/PARTAGE) --> bibi, a priori membre du groupe staff et plus largement compté parmi le everyone = other : la 3è roue de la charrette des accédants, récupère alors la permission d'écriture : w=2 à l'espace du dossier PARTAGE de manière automatique, sans besoin d'authentification par son mot-de-passe admin --> il peut donc, à l'égal de l'owner du dossier = toto affecter l'existence de l'espace du dossier sans entraves, càd. ajouter/supprimer des fichiers (j'exclus ici une arborescence complexe de sous-dossiers pour simplifier l'examen théorique - et par suite la rhétorique de l'exposé).

--------------------​

- b) Mais un problème plus épineux subsiste : celui qui concerne les permissions intrinsèques aux fichiers contenus dans l'espace du dossier PARTAGE. Car si la récupération par bibi en tant que membre du groupe staff d'un droit d'écriture : w=2 à l'espace contenu du dossier lui assure un "pouvoir existentiel" sur les fichiers y recelés (pouvoir les supprimer) en tant qu'ils dépendent de l'espace du dossier où il a droit d'écriture ; il n'en reste pas moins que bibi se trouve dépourvu de droit d'écriture du contenu de ces fichiers, puisque l'umask : 022 s'applique également à eux à leur création par toto, de sorte qu'il sont en 644 en sa défaveur --> bibi peut donc les lire, mais pas les écrire ("éditer"), et un fichier étant un "terme d'arborescence", la non-permission d'écriture est ici un absolu non susceptible d'être outrepassé par une authentification grâce au mot-de-passe admin. bibi n'a alors que la solution classique dans cette occurrence, qui consiste à réaliser une copie d'un fichier - dans ou hors de l'espace de PARTAGE - ce que sa permission d'écrire à l'espace du dossier lui confère, avec la conséquence que l'umask : 022 joue ce coup-ci en sa faveur, en le rendant l'owner de la copie, qui devient par là éditable en écriture. Ne resterait alors qu'à supprimer (grâce au droit d'écriture de l'espace du dossier PARTAGE) le fichier original, et à restaurer le titre du fichier copié à l'identique du fichier supprimé. Ainsi, la situation serait retournée en faveur de bibi sur le fichier édité et au détriment désormais de toto dont le fichier originel a été supprimé.

En généralisant : tous les fichiers créés par toto dans PARTAGE seront à cause de l'umask : 022 soustraits directement à la permission d'écriture de leur contenu pour bibi et vice-versa pour les fichiers créés par bibi dans PARTAGE qui seront soustraits directement à la permission d'écriture de leur contenu pour toto. Seule la méthode indirecte : copie --> édition --> suppression de l'original --> renommage de la copie à l'identique de l'ex-original permet de contourner la limitation de la permission d'écriture du contenu du fichier. Comme on le voit, un sacré embarras dans la pratique. Dont découle une question : existe-t-il y moyen de disribuer équitablement la permission d'écriture au contenu des fichiers créés alternativement par chaque accédant autorisé à l'espace du dossier PARTAGE (càd. toto & bibi) afin de simplifier les manipulations dans la pratique?

--------------------​

 

[Membre supprimé 1060554]

[malgré la permission des 20 000 cararactères, la rhétorique de macomaniac a outrepassé cette limite - d'où la répartition du message sur 2 entrées successives...]

- c) J'ai toujours considéré qu'il y a là une lacune logique dans l'organisation d'OS X : l'absence d'un procédé récursif a priori qui, fixant une permission sur un dossier, l'étendrait ipso facto aux éléments créés dans ce dossier par divers utilisateurs. En effet, à supposer que toto passe une commande de type : sudo chmod -R 777 /Shared\ Items/PARTAGE, l'option récursive : -R va certes étendre le droit d'écriture au contenu des fichiers inclus dans ce dossier à "tous", mais c'est là un procédé récursif a posteriori qui n'empêchera nullement qu'à la création de nouveaux fichiers par toto ou bibi, l'umask : 022 sera derechef actif a priori sur les permissions de ces fichiers, de sorte que l'admin qui n'est pas l'owner n'aura pas a priori la permission d'écriture au contenu du fichier en mode direct. De même, à supposer qu'on fixe une ACL récursive sur le dossier PARTAGE attribuant sa propriété en mode "co-owner" à bibi en sus de toto en mode étendu aux fichiers contenus (par la commande : sudo chmod -R +a "bibi allow write" /Shared\ Items/PARTAGE), cette ACL récursive n'a qu'une valeur a posteriori (elle s'applique aux fichiers déjà contenus) qui ne va en aucune façon affecter a priori les nouveaux éléments ajoutés par un des 2 admins. On est donc alors au "rouet" : il faudrait sans arrêt repasser une commande récursive a posteriori pour étendre la permission d'écriture au contenu des fichiers, sachant que le filtre umask : 022 qui s'applique a priori à la création de nouveaux fichiers par chaque admin en sa faveur seule en ce qui concerne la permission d'écriture va indéfiniment re-créer le problème. C'est le Tonneau des Danaïdes, où il faut sans cesse "boucher" la "fuite" des permissions d'écriture à chaque déversement de nouveaux fichiers dans le "tonneau" : PARTAGE.

☞ Il existe à ma connaissance 2 procédés qui permettent de "colmater" la "fuite de permission d'écriture aux fichiers" suscitée par l'automatisme de l'umask : 022 par défaut -->

--------------------​

- d) L'automatisation par un cron de la commande récursive a posteriori étendant la permission d'écriture (par ACL ou par bit=w) à l'arborescence du dossier PARTAGE. On peut ainsi envisager un Cron du Système (user=root) appliquant récursivement à chaque minute une commande du type : /bin/chmod -R 777 /Shared\ Items/PARTAGE, et en pratique ça marche bien, quoique, théoriquement parlant (c'est-à-dire à contempler la chose en idée), cette solution de rattrapage a posteriori récurrent ressemble à l'acte d'écoper sans cesse une barque qui prendrait l'eau sans qu'on puisse colmater la brèche - procédé qui se borne à "gagner du temps"...

--------------------​

- e) La modification a priori de la valeur par défaut de l'umask de manière à supprimer le problème en amont. Ce me semble la seule solution drastique, mais qui offre la limitation de ne valoir qu'en mode local (pour tous les utilisateurs d'un seul et même Mac - ce qui laisse ouvert le problème de partage à distance par des utilisateurs qui n'éditeraient pas la valeur a priori de l'umask dans leur propre OS...).

Le principe de ce procédé est le suivant : il suffit de créer (car il n'existe pas a priori) un fichier intitulé strictement : launchd-user.conf at: /private/etc contenant la simple mention : umask 000 et dont les droits soient : -rw-r--r-- root wheel (644 0:0) --> alors, avant toute ouverture de session graphique d'utilisateur, le processus parent launchd lira cette instruction de /private/etc/launchd-user.conf et la lui fera "over-ride" ("outrepasser") l'instruction de l'umask : 022 par défaut pour fixer une valeur de umask : 000 corrigée qui s'appliquera a priori à toute création de dossiers/fichiers par tous utilisateurs à partir d'une session ouverte de l'OS --> les dossiers seront donc a priori en permissions : 777 (maximum théorique) - 000 (umask corrigé) --> 777 (permission d'écriture à tous) ; les fichiers (non exécutables) seront de leur côté a priori en permissions : 666 (maximum théorique) - 000 (umask corrigé) --> 666 (permission d'écriture à tous). Si le fait d'accorder aussi la permission d'écriture au tout-venant du other (= everyone) paraissait choquante, alors il suffirait de restreindre la valeur de l'umask édité à : 002 dans le fichier /private/etc/launchd-user.conf avec la conséquence --> les dossiers seront donc a priori en permissions : 777 (maximum théorique) - 002 (umask corrigé) --> 775 (permission d'écriture à tous, sauf everyone) ; les fichiers (non exécutables) seront de leur côté a priori en permissions : 666 (maximum théorique) - 002 (umask corrigé) --> 664 (permission d'écriture à tous, sauf everyone).

La réalisation de ce procédé peut être la suivante (par commodité) : saisir dans le «Terminal» :

sudo touch /private/etc/launchd-user.conf

et ↩︎ (presser la touche 'Entrée' du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> saisir le mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> ce qui crée à l'endroit voulu un fichier vide du nom voulu, avec les droits voulus (-rw-r--r-- root wheel).

Lancer alors ☞TextWrangler☜, naviguer au fichier vide /private/etc/launchd-user.conf, saisir purement et simplement sans rien d'autre la mention : umask 000 («TextWrangler» demande pour cela si on veut vraiment déverrouiller - "unlock" - le fichier pour écriture --> répondre oui) et sauvegarder l'édition («TextWrangler» demande alors une simple authentification par mot-de-passe admin et les droits originels root:wheel sont préservés sur le fichier). Re-démarrer pour que le processus launchd prenne en compte la nouvelle valeur de l'umask : 000 (et ce sera désormais le cas à chaque démarrage du Mac) --> le problème des droits d'écriture est réglé pour tous en local dans l'espace du partage : tous peuvent écrire désormais le contenu des fichiers a priori <et ça s'applique bien entendu également aux dossiers créés par quiconque dans un espace de partage : ils sont "scriptibles" par tous a priori [«TextWrangler» permet à tout moment de ré-éditer le fichier launchd-user.conf pour restaurer la valeur de l'umask au défaut : 022. La suppression du fichier launchd-user.conf de /private/etc aurait le même effet].​

♧​

 

[FrançoisMacG]

Six mois après, tu as peaufiné ta réponse !

 

[Membre supprimé 1060554]

Six mois après, tu as peaufiné ta réponse !

Comme tu vois, il n'y a pas que le CoreStorage dans la vie, il y a aussi l'umask...

​

[1 ans et 4 mois après, tu veux dire... C'était en pleine sortie de «Mavericks 10.9.0» : le forum ressemblait à un hôpital de campagne à l'heure d'une épidémie foudroyante. J'avais repêché le message esseulé de nitramcastel et chez lui ça se compliquait, car il s'agissait d'un dossier partagé accessible sur un réseau local. Si on ne peut pas imposer l'édition de l'umask sur chaque bécane, le mieux c'est encore un cron du système qui rétablisse tà chaque minute en mode récursif les permissions sur le dossier à 777. Ou, en plus raffiné, un cron "minute" encore appliquant récursivement une cascade d'autant d'ACL de co-propriétaires du dossier qu'il y a d'utliisateurs...]​

 

[bompi]

On peut imaginer un procédé qui change automatiquement les droits affectés aux fichiers dans ce répertoire (ou dossier).

Une méthode simple, rustique et de faible performance consiste à créer une tâche automatique qui, chaque minute, réapplique les droits souhaités aux fichiers. C'est pas génial mais ça peut fonctionner comme souhaité (si on peut attendre une minute au maximum...)

Une méthode moins rustique consisterait à faire la même chose dans une "action sur dossier" (folder action).
Ou faire quelque chose de semblable avec launchd (voir par exemple ici ce qui est dit au sujet de postfix).