permissions (ouvrir des documents transférés d'un autre Mac)

Je vais me coller une aspirine au fond d'un verre et y transférer un conséquent volume d'H2O.

☝︎:D Boufre! Démasqué le maco : c'était lui! c'était bien lui! - Dr_Migraine... :D

♤

Si le cœur vous dit de continuer à aider l'auto-didacte cafouilleux que je suis à mettre de l'ordre dans ses connaissances disparates et inexactes : que valent ces axiomes ?

- Copier efface les ACL héritables, déplacer conserve POSIX-ACL héritables-ACL explicites.

- Archiver un fichier efface toutes ses ACL.

✷

Depuis le «Terminal», je crée par touch sur le Bureau de ma session-admin maco un fichier toto qui a les droits suivants :

Bloc de code:
-rw-rw-r--   admin  staff

<admin est le nom de compte-admin secondaire de mon Mac ; staff possède des permissions rw = Lecture et écriture par défaut, car j'ai édité l'umask à 002 dans mon OS, donc les fichiers sont créés en valeur octale : 664 par défaut ; j'ai fait un chown sur le fichier créé pour établir admin en propriétaire>

Je fais un copier dans le presse-papier, puis un coller sur le Bureau &#9758; j'obtiens un fichier toto 2 dont voici les droits :

Bloc de code:
-rw-rw-r--   maco  staff

Il y a eu changement de propriétaire du fichier.

&#10058;

Supposons que je crée une ACL sur le fichier toto afin d'obtenir dans une fenêtre d'info :

Bloc de code:
maco (Moi)  lecture et écriture
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

un copier dans le presse-papier puis un coller sur le Bureau donne un toto 2 dont les droits sont :

Bloc de code:
maco (Moi)  lecture et écriture
maco (Moi)  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

Il y a bien changement de propriétaire + conservation de l'ACL préalable [NB. Le propriétaire est toujours listé juste au-dessus du groupe, l'usager_accédant par droit d'ACL est toujours listé en position supérieure]

&#10045;

Maintenant je compresse au format .zip le fichier toto dont les droits sont :

Bloc de code:
maco (Moi)  lecture et écriture
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

en décompressant l'archive sur le Bureau de la session ouverte de maco j'obtiens un fichier toto 3 dont voici les droits :

Bloc de code:
maco (Moi)  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

Non seulement le propriétaire est substitué, mais l'ACL est effacée.

&#10044;

Maintenant, par la commande mv je déplace le fichier toto dont les droits sont :

Bloc de code:
admin  lecture et écriture
maco (Moi)  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

du volume de mon OS sur le volume indépendant de mes données supporté par une partition de mon Disque Interne. J'obtiens dans ce volume un fichier toto dont les droits sont :

Bloc de code:
admin  lecture et écriture
maco (Moi)  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

Mais si j'avais un fichier toto dont les droits étaient :

Bloc de code:
maco (Moi)  lecture et écriture
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

j'obtiendrais après déplacement :

Bloc de code:
maco (Moi)  lecture et écriture
maco (Moi)  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

Il y a donc conservation d'ACL mais substitution (s'il y a lieu) du propriétaire POSIX.

&#9831;

&#9758; D'après cette courte expérimentation, il me paraît que :

  • Copier est conservatif d'ACL mais substitutif de propriété POSIX - les accédants groupe et autre ainsi que leurs permissions demeurant inchangés.

  • Désarchiver est destructif d'ACL et substitutif de propriété POSIX - les accédants groupe et autre ainsi que leurs permissions demeurant inchangés.

  • Déplacer est conservatif d'ACL mais substitutif de propriété POSIX - les accédants groupe et autre ainsi que leurs permissions demeurant inchangés, càd. une opération équivalente à copier.

Je suis donc d'accord avec l'axiome de François concernant désarchiver (destruction d'ACL) mais je note une substitution de propriété POSIX ; par contre copier et déplacer me paraissent équivalents : substitution de propriété POSIX au profit de l'agent_opérateur + conservation d'ACL de propriété, le reste inchangé.

&#9825;
 
Dernière édition par un modérateur:
Mais si on récupère la propriété d'un fichier sans s'assurer au préalable que le cédant en était bien le propriétaire légitime…. c'est du recel pur et simple!

Donner par le détail la façon de s'approprier les droits sur un fichier tombé du camion, je trouve que les modos devraient sévir et fermer ce fil où sévissent de dangereux pirates! :zen:
 
Pour continuer le brillant exposé de macomaniac, j'ai vérifié ce matin que la commande cp :
- par défaut ne conserve pas les ACL
- encore moins si on utilise l'option -X
- mais conserve ACL et ressources avec l'option -p
 
Il faut rajouter des options à cp pour avoir l'action Copier,

et mv me semble se rapprocher plus de Couper-Coller que de déplacer

= vous compliquez encore les choses !
 
Bientôt, ça va être de notre faute !

:D
 
mv me semble se rapprocher plus de Couper-Coller que de déplacer

Admettons que déplacer au sens restreint équivaille à changer le lieu d'un fichier dans les limites de l'espace global d'un même volume (et non pas transférer un fichier de l'espace d'un volume A à l'espace d'un volume B). En ce sens restreint, il s'agit d'une translation. Je me donne alors comme espace à l'intérieur duquel vont s'opérer les translations de fichier celui du volume de mon OS. Le procédé de translation va être purement graphique : glisser-déposer avec le pointeur.

&#9828;

Supposons-y donc mon fichier toto résidant sur le Bureau de la session ouverte de maco avec comme droits :

Bloc de code:
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

Je translate le fichier toto du dossier Desktop à tout autre lieu compris dans le répertoire home de maco : le dossier Documents ou même l'emplacement_racine du répertoire maco : l'espace où sont compris les divers dossiers de maco créés avec le compte. À l'arrivée, les droits de toto sont :

Bloc de code:
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

&#9758; la translation 'intra-domiciliaire' n'opère aucun changement de droits.

&#10057;

Maintenant, je translate le fichier toto d'un lieu quelconque du répertoire domiciliaire maco à un lieu quelconque 'extra-domiciliaire', càd. relevant de l'espace-système, par exemple l'emplacement-racine de l'OS. J'ai besoin pour opérer cette translation de m'authentifier avec le mot-de-passe admin de maco, puisque la translation affecte l'espace-système dans un de ses lieux. À l'arrivée, mon fichier toto a pour droits :

Bloc de code:
admin  lecture et écriture
staff  lecture et écriture
everyone lecture seulement

&#9758; la translation 'extra-domiciliaire' n'opère aucun changement de droits.

&#10034;

À présent, je veux opérer une translation inverse du fichier toto d'un lieu de l'espace-système à un lieu de l'espace domiciliaire de maco. 2 méthodes sont possibles :

  • Je fais un glisser-déposer de toto de son lieu de résidence dans l'espace-système à un lieu d'accueil dans l'espace-domiciliaire de maco, le Bureau par exemple &#9758; le fichier n'est nullement supprimé de l'espace-système, mais une copie est créée dans l'espace-domiciliaire. Le fichier toto créé sur le Bureau de maco a pour droits :

    Bloc de code:
    maco  lecture et écriture
    staff  lecture et écriture
    everyone lecture seulement

    &#9758; Comme pour toutes les copies, l'agent_opérateur devient le propriétaire POSIX de la copie, les autres droits restant inchangés.


  • J'opère une mise à a corbeille du fichier toto résidant dans son lieu de l'espace-système, ce qui exige une authentification-admin de maco, car il s'agit d'une modification de l'espace-système. Puis j'opère au pointeur un glisser-déposer de la corbeille à un lieu de l'espace domiciliaire de maco, le Bureau par exemple. À l'arrivée, les droits de toto sont :

    Bloc de code:
    admin  lecture et écriture
    staff  lecture et écriture
    everyone lecture seulement

    &#9758; Il y a conservation des droits du fichier sans changements.

&#9831;

&#9758; En résumé :D :

  • La translation intra-domiciliaire est conservative ;
  • La translation extrapolante ('home' --> 'système') est conservative ;
  • La translation intrapolante ('système' --> 'home') n'est conservative que par l'intermédiaire de la corbeille, jamais par transfert direct qui équivaut toujours à une copie avec changement de propriété appropriant la copie à son créateur (l'agent-opérateur dont 'home' est l'espace domiciliaire).

&#9825;
 
Salut tout le monde,

j'ai lu en diagonale ce qui est dit plus haut. Très intéressant mais etes vous vraiment obligé d'utiliser un vocabulaire et une syntaxe ultra austère et soporifique ? (je repète : et pourtant l'information que vous apportez à une grande valeur.)


Je souhaite partager des fichiers entre les différents utlisateurs de mon ordi. Je créée donc un dossier partagé dans "/Volumes/Stockage/Users/Partage" auquel j'attribue les droits 777. Et voila comment on arrive sur des posts comme celui-ci : je me rend compte que j'ai beau y déposer des fichiers ceux-ci sont toujours illisibles (ou uniquement read) par mes autres utilisateurs (petit icone "stop" sur le fichier ou le dossier").

Ce qui est étrange c'est que certains fichiers sont en 700, d'autres en 755 et encore d'autres en 644...

Honnêtement, je suis perdu...

A question simple, je demande une réponse simple. Comment fait-on pour créer un dossier partagé (entre les users) ou l'on peut déposer des fichiers/dossiers sans avoir à faire cmd+I, puis 777, appliquer aux éléments inclus ?


(mon but : avoir un dossier "musique" et un dossier "image" dans partage consultable par tous les users du mac, et surtout ne pas avoir à réajuster les droits en permanence...)
 
Salut fresh1treuk.

macomaniac accepte de bon c&#339;ur ton jugement sur ses contributions dans ce fil :

un vocabulaire et une syntaxe ultra austère et soporifique

Il arrive que mon intérêt s'aiguise pour d'infimes questions de détail et comme j'ai la prose byzantine plutôt que concise - eh bien! le résultat ressemble à une tartine des plus indigeste :D.

&#9828;

Le problème que tu relates rejoint directement un des points discutés précédemment : un fichier déplacé dans un dossier ne prend pas automatiquement les droits de ce dossier mais conserve ses propres droits préalables en règle générale. Si je crée par exemple un fichier toto dont les droits sont : 600 maco staff everyone sur mon Bureau, déplacer ce fichier dans un dossier accessible dont les droits sont 777 maco staff everyone (disponible donc en entrée, lecture et écriture, outre à maco, à tout 'ayant-compte' sur le Mac membre de ce fait du groupe staff et même plus largement à n'importe qui) ne va rien changer à la nature de mon fichier toto. Uniquement accessible à moi : maco son propriétaire, il est inaccessible à tout autre.

Afin d'éliminer une difficulté supplémentaire qui pourrait être liée à l'emplacement du dossier d'accueil, quand tu dis que tu as créé ton dossier_partagé à l'adresse : /Volumes/Stockage/Users/Partage, je pense qu'il s'agit d'un lapsus et que tu as voulu écrire : /Volumes/Macintosh HD/Users/Partagé. Tu as donc créé tout à fait judicieusement ton dossier d'accueil : dossier_partagé dans le sous-répertoire Partagé du répertoire des Utilisateurs de l'OS. En effet, quoique situé dans l'espace-système qui normalement requiert une authentification par un mot-de-passe admin dès qu'on ne se contente pas d'entrer dans un de ses répertoires et d'en lire le contenu, mais qu'on veut y écrire quelque chose (ôter ou ajouter un élément) ; le sous-répertoire 'Partagé' du répertoire Utilisateurs possède le privilège d'autoriser immédiatement tout un chacun à entrer, lire & écrire dans son espace.

Au cas où ton adresse : /Volumes/Stockage/Users/Partage ne serait pas un lapsus, mais bien l'indication d'un dossier dédié au partage créé dans le répertoire normalement invisible Volumes, je pense que ce serait une erreur d'y maintenir le dossier d'accueil dossier_partagé, car il ne s'agit pas d'un 'volume' mais d'un 'dossier', et parce que l'espace du répertoire Volumes ne peut être écrit qu'à la condition de s'authentifier par un mot-de-passe admin à chaque fois.

&#9831;

En supposant, donc, que le dossier d'accueil que tu as créé est bien à l'adresse en droits d'accès complets : Macintosh HD/Utilisateurs/Partagé sous l'intitulé : Dossier_partagé avec droits : 777 fresh1treuk staff everyone, alors le problème se réduit au 1er point que j'ai évoqué précédemment : les fichiers, voire dossiers, que tu vas y déplacer à partir de ton propre espace d'utilisateur-admin fresh1treuk vont strictement conserver leurs droits initiaux, sans du tout être affectés par le caractère 'ouverts à tous les vents' (= 777 fresh1treuk staff everyone) du dossier d'accueil Dossier_partagé. Un fichier toto dont les droits sont 600 fresh1treuk staff eveyone est inaccessible par quiconque n'est pas son propriétaire fresh1treuk. Et tout à l'avenant. Il faut donc régler la question des droits d'accès a priori, puisqu'elle n'est pas réglée a posteriori par le déplacement dans le dossier d'accueil.

Comme tu peux le voir, je n'arrive pas là encore à éviter la prose bysantine qui se complaît à scruter des détails à l'infini :D.

Pour ce qui est, donc, des droits d'accès a priori des fichiers et dossiers que tu pourras être amené à déplacer de ton espace d'utilisateur dans le dossier d'accueil Dossier-partagé, j'entrevois 2 grands cas de figure :

  1. Il s'agit d'éléments dont tu n'es pas le créateur à partir de ton espace d'utilisateur, mais d'éléments créés extérieurement à lui que tu te contentes d'approprier à cet espace (comme si tu déplaces les photos d'une carte-mémoire sur ton Bureau, ce qui revient à établir une copie, ou si tu télécharges des éléments, ce qui revient encore à une copie dans ton espace domiciliaire). Alors, en règle générale, ces éléments vont être en 755 fresh1treuk staff everyone pour les dossiers et en 644 fresh1treuk staff everyone pour les fichiers, càd. que l'écriture est réservée à fresh1treuk qui s'en est approprié la propriété par copie des éléments à son espace. Tu remarqueras qu'un fichier, à la différence d'un dossier, a 6 en permissions plénières (et pas 7 comme un dossier), car un fichier 'ordinaire' est dépourvu de permissions d'exécution (= 1), donc a les permissions 4 (lecture) + 2 (écriture) = 6 ; là où un dossier possède des permissions plénières de 7, car la permission d'exécution (= 1) y est pertinente, signifiant la possibilité d'exécuter l'entrée dans l'espace du dossier, pour pouvoir ensuite y lire et/ou y écrire. Les seules exceptions sont les fichiers exécutables (dits 'binaires'), qui sont des programmes, où les permissions plénières sont régulièrement de 7 car la permission d'exécuter le programme y est pertinente.

    &#9758; pour ces éléments appropriés (par copie) à ton espace d'utilisateur en provenance d'une source extérieure, je ne vois pas d'autre solution a priori que d'étendre leurs permissions au coup par coup à 777 pour les dossiers et 666 pour les fichiers dans le but d'un accès total une fois que tu les auras déplacés dans ton dossier d'accueil Dossier_partagé où ils vont conserver leurs droits préalables. Je n'ai personnellement jamais trouvé de solution automatique satisfaisante pour de tels éléments d'origine extérieure à l'espace de ma session, dans la perspective d'un déplacement ultérieur à l'espace Partagé des Utilisateurs. J'opère donc à la main a priori la rectification préalable des permissions, dans une fenêtre d'info du Finder en mode graphique.

  2. Il s'agit d'éléments (dossiers et/ou fichiers) dont tu es le créateur à partir de ton espace d'utilisateur. Pour le cas en question, par contre, je possède une solution automatique dont je me sers comme d'un procédé par défaut. Pour ne pas 'compliquer' ce § excessivement byzantin :D, je reporte sa description au paragraphe qui suit &#9758;

&#9825;

Il faut savoir que, pour tout élément créé par un utilisateur dans l'espace global de l'OS d'un Mac, le Système impose des droits par défaut. Pour ce qui est des accédants à l'élément, la règle par défaut est : Moi (= propriétaire) staff everyone ; et pour ce qui est des permissions accordées à ces 3 sortes d'accédants, le Système filtre par défaut la valeur permissive totale (qui serait de 777 pour les dossiers et de 666 pour les fichiers -non éxécutables-), en soustrayant à cette valeur théorique la valeur octale 022. Ce qui donne, à la création de tout dossier, des permissions en 755 et à la création de tout fichier des permissions en 644. Cela revient à dire, en synthèse, que les droits d'écriture sont strictement réservés à Moi (= propriétaire). Ce filtrage a priori par défaut des permissions à la création d'éléments par un utilisateur dans l'espace de l'OS de la part du Système s'appelle l'umask.

Il est possible d'éditer cette valeur par défaut de 022 afin d'atténuer, voire de neutraliser l'umask et donc d'étendre les droits d'écriture des éléments créés. Voici comment :

  • Tu vas à /Applications/Utilitaires et tu lances «Terminal.app». Dans la fenêtre qui s'affiche, tu fais un copier-coller de :

    Bloc de code:
    sudo touch /etc/launchd-user.conf

    et &#8617;&#65038; (presse la touche 'Entrée' du clavier pour activer la commande). Une demande de password s'affiche. Tape ton mot-de-passe admin à l'aveugle (aucun caractère ne se montrant à la frappe) et derechef fais &#8617;&#65038;. Un fichier vide au format .txt vient d'être créé dans le répertoire invisible /etc. Un fichier intitulé launchd-user.conf à cet endroit a la propriété de s'adresser au processus launchd qui, une fois que le kernel a chargé le Système Unix de l'OS, prend le relai pour charger le reste du Système avec les paramétrages de fonctionnement. Donc le processus launchd, avant l'ouverture d'aucune session graphique d'utilisateur, aura chargé les paramètres de launchd-user.conf comme valeurs par défaut s'appliquant à tout utilisateur de l'OS actif. Le fichier créé à partir du «Terminal» en mode sudo possède les bons droits a priori : 644 root wheel everyone.

  • Comme le fichier est vide de paramétrages, mais qu'il est toujours difficile d'éditer un fichier-système dans un emplacement protégé comme l'est désormais /etc/launchd-user.conf, le mieux est de télécharger et d'installer le logiciel d'édition de fichiers-système &#9758;TextWrangler&#9756; (clique sur le bleu : c'est un lien). Ensuite, comme le fichier /etc/launchd-user.conf est d'un accès difficile à cause de l'invisibilité de son répertoire d'accueil, tu fais dans le Finder &#8984;&#8679;G (cmd + maj + G) et dans la fenêtre de saisie qui s'affiche tu renseignes :

    Bloc de code:
    /etc

    et 'Aller'. Tu repères ton fichier launchd-user.conf, tu fais un clic_secondaire dessus et tu demandes : ouvrir avec pour naviguer jusqu'à «TextWrangler.app». Tu ouvres le fichier vide dans une fenêtre de «TextWrangler.app» et tu écris :

    Bloc de code:
    umask 000

    et tu sauvegardes ton fichier. Tu auras à t'authentifier par ton mot-de-passe admin. Tu n'as plus qu'à re-démarrer dans le foulée.

&#9758; tu viens de neutraliser entièrement le filtre umask pour tous les utilisateurs de ton OS (toi comme les autres), ce qui fait qu'à leur création tout dossier sera en permissions 777 user staff everyone et tout fichier en permissions 666 user staff everyone. Aucun problème d'accès a priori. Tu peux à tout moment avec «TextWrangler» ré-éditer ton fichier /etc/launchd-user.conf. Une valeur de 002 donnerait 775 user staff everyone pour les dossiers, et 664 user staff everyone pour les fichiers. 022 rétablirait l'umask par défaut. La suppression du fichier /etc/launchd-user.conf aurait le même effet.

&#9826;

Je n'ai pas évité la prose byzantine - c'est on ne peut plus clair et net :D

Et, avec l'esprit_de_l'escalier qui me caractérise, je viens de m'aviser d'une possibilité qui m'avait échappé : l'adresse /Volumes/Stockage/Users/Partage signfie à tous les coups que tu as 2 disques internes, un SSD où ton OS est installé, et un DDI intitulé Stockage où tu as délocalisé pour gagner de la place le répertoire des Users, leur identité nominale d'ayant-comptes dans l'OS du SSD étant reliée par un chemin absolu à leur répertoire d'utilisateurs résidant sur l'autre volume : le Stockage du DDI. Ah là là! Fichtre et Bouffre - voilà qui ne simplifie pas la donne...

&#9812;
 
Dernière édition par un modérateur:
Et, avec l'esprit_de_l'escalier qui me caractérise, je viens de m'aviser d'une possibilité qui m'avait échappé : l'adresse /Volumes/Stockage/Users/Partage signfie à tous les coups que tu as 2 disques internes, un SSD où ton OS est installé, et un DDI intitulé Stockage où tu as délocalisé pour gagner de la place le répertoire des Users, leur identité nominale d'ayant-comptes dans l'OS du SSD étant reliée par un chemin absolu à leur répertoire d'utilisateurs résidant sur l'autre volume : le Stockage du DDI. Ah là là! Fichtre et Bouffre - voilà qui ne simplifie pas la donne...
Un grand esprit de déduction !!

Effectivement, lassé par la lenteur de nos vieux HDD, j'ai mis un bien plus performant SSD dans ma bestiole ! Mais limité par les très onéreux 120 Go de celui-ci, je l'ai accompagné d'un copain de 1To.

J'ai donc SSD 120go = /Volumes/boot/
dans lequel il y a un /Volumes/boot/users/partagé
(avec un "é", mais je suppose qu'il s'appelle "shared" dans le système.)


HDD 1To = /Volumes/Stockage/
dans lequel il y a /Volumes/stockage/users/mon_nom et /Volumes/stockage/users/partage

----

Je souhaite donc faire de /Volumes/stockage/users/partage un espace central ou je stock un dossier "musique", un dossier "images", et un dossier "font" (librairie de police pour Font Explorer X).

Exemple : une librairie iTunes partagée par plusieurs users de mon mac. Je stock donc le dossier "iTunes" dans
/Volumes/stockage/users/partage/musique/iTunes. J'indique ensuite aux deux iTunes de chaque utilisateur d'aller chercher une librairie à cet emplacement.

J'ai réglé
/Volumes/stockage/users/partage en 777. et j'ai coché le "partage" en faisant cmd+i. j'ai appliqué aux éléments inclus.


Sur tes très bons conseils, j'ai réglé le umask à 000.

Je compte désormais sur les droits des DOSSIERS (ex:
/Volumes/stockage/users/mon_nom/documents) et non des fichiers, pour faire le travail de permission.

---

Si j'ai bien compris Mac os X n'ai pas adapté au schéma que je souhaite réalisé. Ce qu'il appelle un dossier "Partage" est uniquement un endroit ou les utilisateurs DOIVENT déposer des fichiers/dossiers, puis COPIER dans leur espace perso.

Les Users ne peuvent pas travailler de concert dans un espace commun, sous peine d'attribuer leurs droits perso à chaque fois qu'il sauve le document.

Me trompe-je ?


 
Un peu (c'est sans doute dû à la prose trop triste des posts précédents).

Ce qu'on peut imaginer de simple, quoique pas du tout sûr, c'est une tâche de fond qui remet les droits en 666 sur chaque fichier de l'espace partagé.
Soit on fait dans le brutal : un truc qui tourne toutes les n minutes.
Soit on fait dans la finesse : écrire un bout de logiciel qui lorsque l'événement "j'ai tripoté un fichier dans l'espace partagé" se produit, recolle illico les droits que l'on souhaite (un bout de code qui travaille comme Spotlight).

Je pense même que ce bout de code existe déjà quelque part : une recherche s'impose.

NB : Note que tu as tout intérêt à ce que deux instances d'iTunes (c'est à dire l'application lancée deux fois, donc par des utilisateurs différents) ne tripotent pas la même bibliothèque iTunes en même temps...
 
HDD 1To = /Volumes/Stockage/
dans lequel il y a /Volumes/stockage/users/mon_nom et /Volumes/stockage/users/partage

----

Je souhaite donc faire de /Volumes/stockage/users/partage un espace central ou je stock un dossier "musique", un dossier "images", et un dossier "font" (librairie de police pour Font Explorer X).

Soit on fait dans le brutal : un truc qui tourne toutes les n minutes...

&#9758; je te propose un petit explicatif de ce procédé drastique, qui consiste à avoir un cron_fresh1treuk qui va tourner inlassement pour remettre les droits d'aplomb périodiquement sur le dossier central pour toi : /Volumes/stockage/users/partage et, par une commande récursive, sur tous les éléments qu'il contient à l'instant t de l'exécution du cron_d'utilisateur.

&#9826;

Ouvre le «Terminal» et fais :

Bloc de code:
touch ~/Documents/change-droits.sh

Tu viens de créer dans ton répertoire d'usager 'Documents' un fichier_shell vide change-droits.sh. Si j'ai bien suivi le topo, le chemin absolu de ce fichier, étant donné que ton répertoire d'utilisateur est délocalisé du SSD, est : /Volumes/stockage/users/fresh1treuk/Documents. Ses droits (suite à ton édition de l'umask) sont : 666 fresh1treuk staff everyone. Comme ce fichier devra être exécutable par la suite, enchaîne dans le «Terminal» :

Bloc de code:
chmod u+x ~/Documents/change-droits.sh

qui transforme les permissions du fichier en 766 fresh1treuk staff everyone.

Ouvre ce fichier avec «TextWrangler» et fais un copier-coller de :

Bloc de code:
#!/bin/bash
/usr/sbin/chown -R [COLOR="DarkRed"]fresh1treuk[/COLOR]:staff /Volumes/stockage/users/partage
chmod -R 777 /Volumes/stockage/users/partage

[évidemment, tu remplaces fresh1treuk, pris ici pour exemple, par ton véritable nom_abrégé d'utilisateur-admin].

Tu sauvegardes le fichier. Les commandes dans le fichier shell rétablissent récursivement les accédants sur partage à : fresh1treuk staff everyone (par chown) ; et rétablissent récursivement les permissions des accédants renouvelés à : 777 (par chmod). Quel que soit l'utilisateur du contenu de ce dossier, s'il n'est pas toi, il sera forcément un membre du groupe staff (en tant qu'ayant-compte) ou au pire un n'importe qui. Dans tous les cas de figure, les éléments accessibles seront toujours en permissions lecture et écriture au minimum.

[NB. S'agissant d'un dossier créé sur un volume indépendant de celui de l'OS, les commandes chown et chmod me paraissent exécutables initiées par l'utilisateur-admin que tu es, sans surclassement d'autorisation. Ce qui les rend d'autant plus simples à exécuter.]

&#9828;

À présent tu télécharges CronniX 3.0.2 (application selfcontained gratuite) que tu déplaces dans le répertoire général /Applications de ton SSD. Il s'agit d'un logiciel qui fournit une GUI d'utilisateur commode pour la définition de crons, soit d'utilisateur, soit du Système (= processus récurrents, à périodicité déterminable et à tâche déterminable, tournant en toile de fond).

Tu lances «CronniX» et dans sa GUI inspire-toi de cette image où j'ai simulé la mise-au-point de ton cron :

300454_original.png

<évidemment, là encore, tu substitues à fresh1treuk ton véritable nom_abrégé d'utilisateur-admin>

&#9758; le cron est drastique : toutes les minutes, il va activer les 2 commandes du fichier shell qui vont, quoi qu'il en soit, restaurer récursivement les accédants sur ton dossier central partage et tous ses contenus à : fresh1treuk staff everyone ainsi que restaurer récursivement dans la foulée les permissions sur ton dossier central partage et tous ses contenus à : 777 (c'est ce qu'on peut appeler le maximum pour le minimum).

[Le cron est toujours éditable, voire supprimable, dans la GUI de «CronniX - j'espère ne pas avoir 'lâché de wagons' le long des rails de ce post :D]

&#9831;
 
Dernière édition par un modérateur: