Salut
jc.
[Quoique ayant capté l'amicale sollicitation de François 
dans ce fil vespéral ☞tags-mavericks-elements-bibliotheque☜, mon intention de réponse matinale -débile à suivre plus d'un lièvre à la fois- se trouvait déjà toute entière captivée par le passionnant problème de ce fil-ci - si disertement documenté par l'auteur]
Je crois d'abord pouvoir apporter ma contribution sur le point suivant -->
je mets des droits en écriture que pour moi.
Je cherche un peu sur le net. Facile.
Je reformate la carte SD avec le sytème de fichiers Mac OS extended, recopie mes fichiers et mets en écriture que pour moi (lecture pour tous les autres) et en récursif sur tout le contenu de la carte SD. Pas de soucis tout est OK.
Mais quand, elle rentre en session sur son compte, tout le contenu de la carte SD lui est affecté (elle est déclarée en tant que propriétaire !).
DOnc elle prend des droits RW sur tout les dossiers peut donc encore tout effacer !
J'ai l'impression que lors de l'entrée en session, la carte SD est monté automatiquement par l'utilisateur (et ça lui appartient donc.
J'ai juste ou je me trompe ?
Lorsqu'on considère un volume logique non pas 'attaché à demeure' au Mac (comme celui supporté par le disque physique incorporé à l'ordinateur), mais 'attaché provisoirement' (comme celui supporté par une clé USB, un DDE ou encore dans le cas présent une carte mémoire), càd. susceptible de s'en trouver 'détaché' pour être 'attaché' à un autre ordinateur - alors se pose l'intéressante question des
droits de propriété sur ce volume : à savoir l'
utilisateur_propriétaire : u et le
groupe_propriétaire : g.
Le principe de la réponse est clair : l'
ug sur un volume logique n'est jamais adhérent au
système de fichiers (
filesystem) du disque considéré, qui donc monterait intrinsèquement avec le volume et dé-monterait à rebours avec lui --> il ne s'agit donc pas de
bits (l'
u_
bit et le
g_
bit) attribués de manière résidente au
filesystem du disque détachable en question.
L'
ug sur un volume logique, au contraire, est consignée dans une
Base_de_Données de l'OS supporté par le disque interne attaché à demeure à l'ordinateur : la
/private/var/db/volinfo.database. Il s'agit donc de paramètres purement immanents au Système d'Exploitation du disque interne résident, qui se trouvent attribués lors du
montage_en_volume du
filesystem par le
daemon : diskarbitrationd.
2 cas de figure se présentent ici -->
- si l'option de paramétrage : conserver les droits de propriété se trouve consignée comme active dans la base de données de l'OS, alors quelque soit l'espace d'utilisateur à destination duquel le volume du disque attaché se trouve monté, l'ug sur le volume va se conserver de manière fixe (pour autant qu'on ne sorte pas de l'OS où réside la Base-de-Données). Supposant 2 utilisateurs admin en exemple : bibi et nana, si les droits de propriété u sur le volume sont attribués à bibi conformément à l'option : conserver les droits de propriété, alors, lorsque le volume monte à l'espace d'utilisateur de nana, c'est bien toujours bibi seul qui conserve l'u sur le volume.
- si l'option de paramétrage : conserver les droits de propriété se trouve consignée comme inactive dans la base de données de l'OS, alors l'ug sur le volume va varier en fonction de l'identité propriétaire de l'espace d'utilisateur auquel monte le volume en question. Supposant toujours nos 2 utilisateurs admin en exemple : bibi et nana, si les droits de propriété u sur le volume sont attribués conformément à l'option : conserver les droits de propriété = désactivé, alors lorsque le volume monte à l'espace-utilisateur de bibi, l'u sur le volume = bibi, et lorsque le volume monte à l'espace-d'utilisateur de nana, l'u sur le volume = nana.
☞ Il est clair que, regardant ta carte-mémoire attachée au Mac tout en étant susceptible d'être détachée, le paramétrage dans la base de données
/private/var/db/volinfo.database relatif à ce disque et présidant à son montage en volume est de type :
conserver les droits de propriété = désactivé. Il ne te sert donc à rien de te préserver le privilège de propriété sur le volume de type
u = bibi, avec les
permissions afférantes
(lecture/écriture/exécution) et d'exclure la permission d'
écriture de
g = groupe, car lorsque le volume montera à l'espace d'utilisatrice admin de
nana, le paramètre
conserver les droits de propriété = désactivé assimilera l'utilisatrice active à l'identité :
u, avec donc les
permissions afférantes en
lecture/écriture/exécution.
Il faut donc, pour préserver l'
identité-propriétaire : ug, virer le paramétrage dans la base de données
/private/var/db/volinfo.database relatif au disque de la carte-mémoire à
conserver les droits de propriété = activé.
- Tu peux le faire en mode graphique en ouvrant dans ta session (= bibi) une fenêtre d'information du Finder (⌘I sur le volume monté de la carte), en déverrouillant le cadenas d'administration et en décochant la case de l'option tout en bas : Ignorer les autorisations sur ce volume (il est à noter qu'en mode graphique, l'emploi des options porte sur une énonciation_négative par défaut relative au paramètre implicite : conserver les droits de propriété) ;
- Tu peux le faire en mode textuel (ligne de commande) en ouvrant une fenêtre du «Terminal» (Applications/Utilitaires) et en passant une commande du type :
Bloc de code:
sudo diskutil enableOwnership /dev/[COLOR="Red"]disk1s2[/COLOR]
(vraisemblablement le device_identifier du volume de ta carte que tu vérifies dans l'«Utilitaire de Disque» en faisant ⌘I sur le volume monté de la carte) et ↩︎ (retour-chariot en pressant la touche 'Entrée' du clavier pour activer la commande) --> demande de password affichée --> taper le mot-de-passe admin de bibi à l'aveugle -aucun caractère ne se montrant à la frappe- et derechef ↩︎ (il est à noter, encore, qu'en mode textuel, l'emploi des options procède par énonciation_affirmative du paramètre : conserver les droits de propriété)
-----♤
Je préfère te prévenir, nonobstant, que l'établissement du paramètre
conserver les droits de propriété = activé au nom de
bibi sur ta carte-mémoire ne créera pour
nana qu'un obstacle
relatif et en rien
absolu dans sa session, dans la mesure où elle possède des privilèges
admin. Si elle veut éditer en
écriture l'espace du volume de la carte (ajouter des fichiers/supprimer des fichiers), son privilège
admin confronté au seul obstacle du paramètre :
conserver les droits de propriété = activé au nom de
bibi se dénouera par l'affichage d'une boîte de dialogue, demandant si
nana veut vraiment utiliser ses droits admin pour éditer l'espace de la carte, et si oui, d'avoir à s'authentifier par son mot-de-pase admin. Une fois fait, rien n'empêchera
nana =
admin d'affecter l'espace du répertoire 'carte' en ajoutant le fichier voulu ou en supprimant le fichier voulu à coups de mot-de-passe chaque fois.
-----♧
En réfléchissant à ton intéressant problème tel que tu le synthétises ainsi :
Donc je cherche une solution pour empecher le montage auto de cette carte pour certains utilisateurs.
A moins que vous ayez une autre suggestion pour obtenir ce que je souhaite ?
Je suis ouvert à toute approche.
Je souhaite simplement qu'il n'y ait que moi qui puisse écrire sur cette carte SD. Idéalement que les autres utilisateurs puissent y accéder en lecture (qques videos et musiques)
je ne pense pas (personnellement) qu'une solution commode puisse consister dans un procédé interdisant le montage en volume du
filesystem de la carte dans toute autre session d'utilisateur que la tienne, car si cela était, ce procédé entrerait en contradiction avec le réquisit : «
Idéalement que les autres utilisateurs puissent y accéder en lecture (qques videos et musiques)» en leur rendant le volume inaccessible. Il serait beaucoup plus simple dans ce cas de détacher physiquement la carte du Mac et de la garder dans ta poche lorsque ta session n'est pas ouverte.
Une solution qui m'est venue à l'esprit serait la suivante : tu laisses, en ce qui concerne le volume de la carte, les choses en l'état --> à savoir, le paramètre
conserver les droits de propriété = désactivé de manière à autoriser un partage théorique de l'espace de la carte entre
bibi (=toi) et
nana (=l'autre).
Mais à présent tu crées 3
dossiers dans cet espace de la carte : un dossier
bibi_réservé (exemple), un dossier
nana_réservé (exemple) et un dossier
bibi-nana_partagé (exemple).
- Sur le dossier bibi_réservé (ton espace d'exploitation réservé sur la carte), tu établis les mêmes droits exclusifs qui sont ceux des dossiers de l'espace-Home d'utilisateur excluant tout autre de l'usage que le propriétaire. Cela s'obtient par des commandes simples dans le «Terminal» du type :
Bloc de code:
sudo chown bibi:staff /Volumes/nom_du_volume_de_la_carte/bibi_réservé
(qui attribue en mode fixe -voir à la fin- le bit:bibi=u sur le dossier - évidemment, dans la pratique, remplacer mes noms fantaisistes par les noms réels de sujet et d'objet) puis -->
Bloc de code:
sudo chmod 700 /Volumes/nom_du_volume_de_la_carte/bibi_réservé
(qui exclut absolument tout autre accédant au dossier que bibi aux permissions : lire/écrire/exécuter) et si tu ne veux pas (par respect pour l'autre) que le dossier bibi_réservé apparaisse par suite porteur d'un ⛔︎ violent lorsque nana le voit depuis sa session ouverte, tu te crées d'abord un alias : bibi_réservé alias de ton dossier d'exploitation dédié sur ton Bureau de session (de manière à pouvoir travailler en accès direct dans cet espace réservé), puis tu ajoutes la commande dans le «Terminal» -->
Bloc de code:
sudo chflags hidden /Volumes/nom_du_volume_de_la_carte/bibi_réservé
qui fixe le flag:hidden (attribut d'invisibilité) sur le dossier dédié --> par suite, dans l'espace du volume monté de la carte, le dossier déjà interdit à autrui par des droits strictement propriétaires se trouve de surcroît frappé d'invisibilité.
✽
- Tu peux procéder équitablement pour nana de la même façon, en attribuant à son dossier dédié des paramètres analogues :
Bloc de code:
sudo chown nana:staff /Volumes/nom_du_volume_de_la_carte/nana_réservé ;
sudo chmod 700 /Volumes/nom_du_volume_de_la_carte/nana_réservé
et tu peux t'abstenir du flag:hidden si tu n'as rien contre la vue d'un sens interdit à ton encontre.
❈
- Par contre, en ce qui concerne le dossier bibi-nana_partagé, après avoir créé ce dossier toi-même, ce qui t'en assure automatiquement la propriété, tu passes une commande du type :
Bloc de code:
sudo chmod +a "nana allow read,write,execute" /Volumes/nom_du_volume_de_la_carte/bibi-nana_partagé
ce qui crée une ACL (droit supplémentaire) instaurant nana en co-propriétaire du dossier. Ainsi, le dossier bibi-nana_partagé se trouverait équitablement dédié au couple, par exemple pour des vidéos/photos utilisables par les 2, à charge de chacun de gérer non-destructivement cet espace commun (sans quel principe éthique implicitement admis comme actif, on se demande bien ce qu'un couple pourrait partager... ).
-----♡
☞ dans les commandes que j'ai proposées, le truc pour se simplifier la vie dans la saisie des chemins aux volumes et/ou dossiers dans le «
Terminal» consiste dans ce qui suit (donné pour un seul exemple et itérable pour toute autre commande) --> saisir textuellement le syntagme préliminaire de la commande = le segment 'opératoire' du type :
et
sauter un espace en pressant une fois la barre d'espacement du clavier, puis faire un
glisser-déposer direct dans la fenêtre du «
Terminal» de l'objet de la commande = 'destination' (volume ou dossier), ce qui renseigne automatiquement le chemin à l'objet et le nom de l'objet.
☞ un point décisif est à noter : à la différence d'un
filesystem supporté par un disque et montable en volume, qui, comme vu en premier, ne supporte pas d'
ug en tant que paramètre inhérent =
bit, mais seulement appliqué au montage en volume par le
daemon : diskarbitrationd après lecture de la Base-de-Données :
/private/var/db/volinfo.database ; lorsqu'il s'agit par contre d'objets qui sont des
fichiers particuliers (soit élémentaires =
files, soit composés -fichiers de fichiers- =
directories), les
droits de propriété = ug se trouvent fixés de façon adhérente sur le fichier en tant que
bits permanents, peu importe l'espace d'exploitation auquel il se trouvent inscrits par le montage du volume qui les supporte.
-----♢
