Partage de fichier+actualisation des autorisations

nitramcastel

Nouveau membre
23 Octobre 2013
2
0
Bonjour à tous,

je souhaiterais obtenir de l'aide à propos d'un problème de partage de fichier. Je vous expose le problème. Dans le cadre d'un usage professionnel, mon iMac possède un dossier partagé (accessible par des macs et PC sous windows) entre plusieurs utilisateurs qui ont un compte sur ma machine. Ce dossier sert essentiellement à faire du stockage de données. Au temps t, j'autorise (en tant qu'administrateur) la lecture et l'écriture sur l'ensemble des sous-dossiers. Par contre, dès que quelqu'un rajoute un fichier dans cette arborescence, les autres personnes ne peuvent pas y accéder, et je dois à nouveau mettre à jour les autorisations depuis le dossier racine, puis dans tous les dossiers inclus.

Existe-t-il une manière de paramétrer les autorisations pour que lorsque quelqu'un rajoute un fichier, les autres utilisateurs qui partagent le dossier puissent y accéder sans que je mette à jour manuellement les autorisations?

Je vous remercie par avance pour votre aide. Si ce problème a déjà été résolu quelque part, merci de me transférer la solution.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 550
22 693
Forêt de Fontainebleau
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 :D. 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...' :D). 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)» :

Bloc de code:
umask 000
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>

&#9816;
 
Dernière édition:

nitramcastel

Nouveau membre
23 Octobre 2013
2
0
Merci Macomaniac pour ta réponse. Effectivement, la vague maverick m'a fait douté de la portée de mon message…… Donc bravo pour ton acharnement à retrouver le message et surtout à y répondre!

A la lecture attentive de ta réponse, il me semble que tu as cerné le problème. Je crois comprendre qu'il n'existe pas de solution idéale, si ce n'est ce que je fais déjà, à savoir remettre à jour les autorisations à chaque fois qu'un des utilisateurs referencés ajoute un fichier, pour que tous les autres utilisateurs referencés. Je vais continuer à creuser.

Question en passant: est-ce que la situation a une chance de changer avec Maverick?

Bonne soirée!
 

defre2937

Membre confirmé
15 Juin 2009
164
1
43
Complètement à l'Ouest....
Bonjour,

juste une idée comme ça en passant...
Essaye de creer un groupe d'utilisateurs auquel tu donnes les droits qui vont bien, si tu ajoutes ensuite tes utilisateurs dans ce groupe, ils ont tous les droits d'écrture sur le dossier et ses sous dossiers....
En outre lorsque tu as un nouvel utilisateur, tu n'as qu'a l'ajouter à ton groupe et hop il bénéficie de l'ensemble des droits immédiatement ;-)

Cela ne résout'il ton problème ?
 

Niconemo

Modo (toujours vivant !)
Modérateur
Club MacG
26 Juin 2001
6 447
455
Rhône-Alpes
Je répond moi-même à defre2937 :

Non, ça ne résoudra pas le problème.
Le problème c'est qu'un fichier créé en dehors du dossier partagé (quels que soient les droits) puis glissé dans le dossier partagé, conservera ses droits d'origine au lieu de se voir appliquer les droits du dossier supérieur. En principe, si le document est enregistré directement dans le dossier partagé, pas de problème de droits.

Il faut donc nécessairement régulièrement, depuis le poste serveur, appliquer les autorisations aux dossiers inclus.

Le problème est très bien décrit ici, avec une solution proposée (une solution au delà de mes compétences) pour appliquer les autorisations automatiquement toutes les 15 minutes par une tâche cron.

J'ajoute que :

1 - Mac OS X server n'a pas ce problème.

2 - Ça fait des années que je cherche régulièrement à résoudre ce problème.
 
Dernière édition:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 550
22 693
Forêt de Fontainebleau
:coucou: Nitramcastel & :coucou: Niconemo.


Je remonte ce fil dont le sujet m'avait intéressé :

comment faire en sorte que, pour un dossier partagé que j'appellerai : partagé, localisé dans l'OS d'un Mac supposons à l'adresse /Shared Items (= dans le dossier 'Éléments partagés' créé par le Système dans l'espace-racine de l'OS, mais ça pourrait être n'importe où pourvu qu'il soit accessible aux partageants) et dont les droits sont fixés une fois pour toute à : 777 user staff everyone (càd. en valeur octale l'équivalent de : lecture/écriture/exécution pour l'admin-propriétaire (Moi), le groupe staff = les ayant-comptes au sens large et les visiteurs everyone = le tout-venant qui peut accéder au dossier) - les documents périodiquement logés dans son espace par les membres du groupe de partageants soient en lecture/écriture/exécution (de l'entrée au répertoire) pour les dossiers, et en lecture/écriture pour les fichiers, ce pour tous?​

Sachant que le fait de loger ces documents dans l'espace du répertoire de partage partagé ne va en aucune façon modifier leurs droits préalables, lesquels seront toujours par défaut en 755 propriétaire groupe tout-venant pour les dossiers et 644 propriétaire groupe tout-venant pour les fichiers, càd. que par défaut seul le 'déposant' des documents aura les droits de lecture/écriture dessus en tant que leur créateur-propriétaire, tandis que les membres du groupe des partageants et plus largement le tout-venant n'auront que des droits de lecture (assortis, pour les dossiers, de la permission exécutive d'exécuter l'entrée à l'espace intérieur du dossier pour pouvoir en 'browser' = 'lire' les éléments contenus).

&#9828;


  • Ma première contribution au règlement de ce problème - ô combien abstruse! :D - était une solution a priori = par l'amont --> sachant que ce qui impose à des documents créés par un utilisateur quelconque les droits restrictifs 755 user staff everyone pour les dossiers et 644 user staff everyone pour les fichiers est le filtre par défaut umask : 022 en valeur octale qui est soustrait a priori par le Système à la valeur octale potentielle maximale = 777 : dossiers et 666 : fichiers pour donner donc par défaut des dossiers en 755 user staff everyone et des fichiers en 644 user staff everyone ; l'astuce consiste à agir sur ce filtre umask, par exemple pour le ramener à 002, voire à 000.

    Il suffit pour cela de créer et d'éditer un fichier /etc/launchd-user.conf à cette valeur (002 ou 000) et tous les items créés par des utilisateurs à partir de sessions ouvertes dans l'espace de l'OS considéré prendront des valeurs de 777 / 666 au maximum, ou de 775 / 664 au minimum, ce qui permet aux partageants du dossier partagé d'avoir a priori des permissions d'écriture sur ces items.

    La limitation est que, si lesdits partageants interviennent dans le cadre d'un réseau (sans Serveur), ils n'ouvrent pas de session dans l'espace de l'OS dont l'umask est édité, mais ne font qu'utiliser des identifiants d'ayant-comptes pour déposer des documents sans ouvrir leur session, ce qui fait que les documents créés dans leur OS propre à filtre umask non édité seront basiquement en 755 / 644 ce qui ne règle pas la question. Il faudrait que chacun édite de son côté l'umask de son propre OS à 002 / 000 pour que les violons soient accordés a priori et l'on n'est jamais sûr qu'ils le feront, à moins d'avoir un pouvoir d'intervention sur leurs OS respectifs.


  • Il se trouve que tout récemment j'ai été amené à rédiger le descriptif d'un procédé a posteriori (= par l'aval) en illustration de la suggestion de bompi d'établir un cron sur le dossier que j'ai appelé ici partagé rétablissant périodiquement (= toutes les minutes ! :D) les droits sur les documents inclus à 777 : dossiers et 666 : fichiers, ce de manière récursive. C'était en réponse au problème soulevé par ccciolll sous un intitulé un peu curieux : &#9758;Créer une dropbox qui gère le partage et permissions&#9756;.

    Le tuto décrivant spécifiquement la procédure à 2 crans (établissement d'un script_shell + établissement d'un cron_système) peut être lu : &#9758;ici&#9756;. Je m'aperçois rétrospectivement que le papier du nommé bruce dont Niconemo avait donné le lien décrit une solution du même acabit (cron activant périodiquement la commande d'un script_shell enchaînant un chown -R user:staff et un chmod -R 777 - les seules différences résidant dans le fait que bruce édite directement le fichier script_shell depuis un traitement de texte du «Terminal» là où macomniac (qui a un poil dans la main) utilise vulgairement «TextEdit» (je pense que passer par «TextWrangler» serait une solution plus commode) ; et dans le fait que bruce édite la crontab en ligne de commande depuis le «Terminal» encore, tandis que le fainéant macomaniac :D propose de passer par la GUI graphique commode du logiciel de crons : «CronniX», lequel est d'un usage enfantin.


  • J'ai fait le test sur un dossier créé ad_hoc sur mon Mac : à chaque saut d'une minute à l'horloge du Mac, tous les éléments inclus dans le dossier qui est la destination de la commande script_shell initiée par le cron voient leurs droits rétablis récursivement à 777 user staff everyone pour les sous-dossiers et 666 user staff everyone pour les fichiers, ce qui remplit la fonction attendue. Je n'ai pas exploré (par flemme) la solution d'un script_de_dossier associant automatiquement à toute modification du répertoire une édition des droits des éléments - nul doute que ce serait un procédé plus élégant :D. Sinon, il faudrait utiliser le logiciel : «Serveur» d'Apple, mais mon intérêt pour la question n'est pas allé jusque là.

&#9831;