10.11 El Capitan Partage de fichiers avec un autre utilisateur de Mac

[mariol66]

Bonjour à tous,

Mon amie utilise son Mac sous El Capitain pour son boulot. Elle dispose de documents Word.
L'autre jour, elle souhaitait créer un utilisateur invité sur son Mac pour sa collègue qui aura sa propre cession et devra avoir accès aux documents word pour les modifier et en créer d'autres.

Le but étant d'avoir deux utilisateurs sur le Mac,
User1qui est admin
User2 qui est standart

Et que les deux utilisateurs ais accès aux mêmes fichiers Word que chaqu'un pourra en modifier le contenus et en créer d'autres (par duplication d'un fichier témoins vide) pour que l'autre y ai accès.

Le User 1 étant admin j'ai donc créé un User 2 en invité.

La seule façon que j'ai trouvé pour que User2 ai accès aux dossier avec toutes les fiches word partagé à été d'activer le partage de fichiers et de déplacer le dossier dans Utilisateurs/Partagé.

Déjà je pensais qu'en faisant clic droit lire les informations du dossier et cocher la case "Dossier partagé" et en ajoutant le droits d'écriture et lecture pour le User2 SANS déplacer le dossier vers utilisateurs/Partagé cela fonctionnerais, mais non.

Je fini par faire un test, le User2 à accès aux fichiers word du dossier situé dans utilisateur/Partagé il peut lire, écrire et créer des nouveaux fichiers à cet endroit.

Seulement tout à l'heure mon amie me dit qu'elle s'est retrouvé bloqué lorsque sa collègue User2 à créé de nouveaux fichiers mais qu'elle n'a eu accès qu'en lecteur seule avec User1. Par contre il faut que je lui redemande si cela le fait aussi avec des fichiers qui auraient été modifiés et non pas créés.

Je dirais à vu de nez qu'il faudrait que depuis l'User2 dans le dossier partagé je mette en lecture et écriture User1 et User2 via Partage et permissions (je l'avais fait depuis le User1).

Mais est-ce que cela devra être changé à chaque création (et modification) d'un fichier Word, est-il possible que cela se fasse automatiquement ?

Enfin chose que je n'ai pas trop bien compris et qui me chagrine un peut. Pour partager le dossier avec l'autre utilisateur interne du Mac j'ai du activer le partage de fichiers via Préférence Sytème/partage de fichiers. Seulement est-ce que ça ne rend pas visible le dossier partagé word sur le réseaux dans lequel le Mac est connecté ?
Mon amie dispose de sa propre Box Pro mais il ne faudrait pas qu'un jour elle se connecte sur un réseau et que des personnes de l'extérieur puisse avoir accès au dossier partagé. Bon, ok si les droits de ce dossier sont uniquement pour User1 et User2 personne ne pourrait y avoir accès mais quand même... est-on obligé d'activer le partage de fichier réseaux pour pouvoir activer le partage entre utilisateur d'un même Mac ?

Merci pour votre aide.

 

[mariol66]

Je reviens pour plus de précisions, je voyais mon amie aujourd'hui et j'en ai profité pour regarder vite fait les paramétrages du dossier partagé.

Donc pour résumé j'ai un dossier TOTO qui est dans Utilisateurs/Partagé

Depuis mon User1 (qui est admin) dans les informations du dossier partage et permissions j'ai:

User1 Lecture/écriture
User2 Lecture/écriture
staff Lecture seulement
everyone Accès interdit (je lui ai modifié sur accès interdit) car en fait je pensais qu'elle disposait de sa propre box mais en fait non, son Mac est relié à un réseau et il ne faut pas avoir accès de l'extérieur (il faut juste un accès à User1 et User2)
Et j'ai validé pour que ces paramètres soient pris en compte dans les sous dossiers et fichiers.

Depuis la cession User1 je peux utiliser mon fichier modèle, le copier et le renommer avec changements, j'y ai accès avec sur le User2.

Les choses se compliquent depuis le User 2 qui est un compte Standard.

J'accède au dossier Toto Partage, je peux ouvrir mon fichier modèle mais dès que je fais une copie ou dès que je modifie un fichier, ces derniers ont leurs permissions qui changent et qui deviennent:

User2 Lecture/écriture
User2 Lecture/écriture
staff Lecture seulement
everyone Accès interdit.

Ce qui fait que lorsque je veux y accéder à nouveau depuis le User1 il n'est qu'en lecture seulement.

Je souhaiterais que TOUT les fichiers et dossiers se trouvant dans le dossier TOTO soit accessibles pour le User1 et le User2 que l'on modifie, créer ou duplique ces fichiers. Est-ce dû à ce que le User2 est en standard et non en admin?

Merci pour votre aide

 

[Membre supprimé 1060554]

Bonjour mariol

Tu soulèves le problème des permissions sur les fichiers créés dans un dossier accédé par 2 utilisateurs.

Ayant personnellement scruté il y a lurette ce problème dans plusieurs fils des forums MaGé > je trouve ici une occasion de me replonger dans des spéculations à ce sujet. Je dirais (cum grano salis pour ce qui est de l'évocation finale des théories du « Contrat Social ») ceci -->

- une fois le service "Partage de fichiers" activé en faveur de 2 utilisateurs sur un dossier donné (ton dossier /Users/Shared/TOTO) => on s'attend à ce que les autorisations affectées au dossier parent TOTO (accès POSIX en lecture/écriture/exécution pour User1 + accès ACL en lecture/écriture/exécution pour User2) => soient affectées récursivement aux éléments enfants du dossier parent partagé : càd. aux fichiers contenus dans le dossier - y compris les objets créés dans cet espace par tel des 2 utilisateurs partageurs.​

- cet "effet de récursivité des autorisations" (dossier parent => contenu enfant) --> n'a cependant rien d'un automatisme dans macOS. Si les autorisations sur un dossier parent permettent à 2 utilisateurs d'entrer dans son espace avec des pouvoirs de lecture et d'écriture à cet espace => cela n'implique en aucune façon (forme, mode ni mesure) que se trouve garanti identiquement un accès au contenu des objets de cet espace (càd. un accès en lecture & écriture au contenu des fichiers).​

- car des objets créés dans l'espace partagé d'un dossier > le sont par l'usage que font tel & tel utilisateur de telle ou telle application (application constituant le médium de lecture / écriture de fichiers). Or l'usage applicatif dans macOS se trouve a priori soumis à un "filtre permissif" qui s'apple l'« umask » (ou masque d'utilisateur). À savoir qu'à la création d'objets par un utilisateur via une application > la valeur permissive totale possible pour les objets créés va se trouver affectée d'une réduction a priori.​

- la valeur permissive totale possible pour un dossier est de 777 en valeur octale où : permission de lire = 4 > permission d'écrire = 2 > permission d'exécuter = 1 ; chacun des 3 chiffres à la suite désignant implicitement la somme octale des permissions pour l'user (user) > pour le primary group (group) > pour le secondary group (other). 777 ne se lit donc pas comme un nombre (sept-cent-soixante-dix-sept) > mais comme l'accollement de 3 chiffres (7-7-7). Donc l'user a des permissions totales possibles de 7 sur un dossier (lecture 4 + écriture 2 + exécution de l'entrée au répertoire 1). Idem pour le groupe principal (staff par défaut) et idem pour le groupe secondaire (everyone par défaut).​

- la valeur permissive totale possible pour un fichier standard est de 666 en valeur octale. Càd. pour l'user lecture 4 + écriture 2 - sans exécution, puisque les fichiers de type exécutable sont considérés comme des objets du Système et pas des objets applicatifs relevant d'un usage d'applications par un utilisateur. Pour le groupe primaire 6 également et idem pour le groupe secondaire.​

 

[Membre supprimé 1060554]

- c'est par rapport à ce contexte de "possibilités permissives totales" => qu'intervient le filtre de l'umask. La valeur de l'umask est toujours par défaut de 022 (en valeur octale) dans le Système de macOS. Càd. que 022 se trouve soustrait à priori lors de la création applicative d'un objet (dossier ou fichier) par un utilisateur => à la valeur octale des permissions possibles totales de cet objet. En conséquence : un dossier BROL créé applicativement par l'utilisateur user1 --> va avoir comme permissions la valeur totale possible 777 - le filtre 022 de l'umask => 755. Ce qui se lit ainsi : l'user (= user1) a des permissions 7 sur le dossier BROL créé (lecture/ écriture/exécution) > le groupe principal staff des permissions 5 (lecture/ exécution sans écriture) et le groupe secondaire everyone idem. Et un fichier brol créé applicativement avec une extension par l'utilisateur user1 --> va avoir comme permissions la valeur totale possible 666 - le filtre 022 de l'umask => 644. Ce qui se lit ainsi ; l'user (user1) a des permissions de 6 sur le fichier brol (lecture/écriture - sans exécution, puisqu'il ne s'agit pas par principe d'un fichier binaire de type Système) > le groupe principal staff des permissions 4 (lecture tout court sans écriture ni exécution) > et idem pour le groupe secondaire everyone.​

- il est évident que 2 utilisateurs intervenant à tour de rôle dans l'espace partagé d'un dossier où ils peuvent entrer et écrire à cet espace => vont effectuer des créations d'objets (dossiers ou fichiers) conformément au principe décrit ci-dessus --> càd. conformément à la soustraction de permissions totales possibles par l'umask. Le dossier BROL créé par l'user1 n'aura de permission d'écriture à son espace que pour user1 comme effet des permissions filtrées 755. Et le fichier brol créé par l'user1 n'aura de permission d'écriture à son contenu que pour user1 encore comme effet des permissions filtrées 644. Ce > car aucune récursivité a priori des permissions du dossier parent => ne s'impose sur les objets enfants créés dans cet espace > les entrants autorisés de cet espace (comme user1 & user2) y gardant leurs "libertés individuelles" en terme de création applicatives d'objets.​

- seul un service (daemon) du Système > peut > dans le cadre d'un "partage de dossier" --> contrer la soustraction a priori par l'umask des permissions totales sur des objets créés > en restaurant l'« état de nature » des permissions totales par suppression de l'« état civil » des permissions réduites par l'umask. Un service restaurant l'« Âge d'Or » de la permissivité totale de tout à tous > contre l'« Âge de Fer » de la permissivité réduite de la propriété à chacun. Car ne pas s'illusionner une seconde ici : la logique de l'informatique n'est jamais que la formalisation d'une politique - jusqu'à la plus petite occurrence de ses objets. Il n'y a aucune neutralité technique.​

 

[Membre supprimé 1060554]

- or ce qui se constate sur-abondamment lorsqu'un utilisateur active les fonctions de partage de dossiers entre des utilisateurs --> ce sont les carences du service de partage invoqué (le daemon du Système) => lequel laisse en place les permissions "civiles" réduites par l'umask lors de la création d'objets > au lieu de ramener l'âge d'or d'une permission totale de l'état de nature. Il paraît que pour certains utilisateurs dans le cadre de tel OS de tel Mac => le service de partage effectue bien sa tâche de "contre-umask" dans l'espace de tel ou tel dossier affecté à un partage. Dans la plupart des autres cas => le service de partage en question ne fait rien du tout et l'umask exerce ses effets à la création d'objets par les utilisateurs dans l'espace du dossier partagé > exactement comme s'il s'agissait de n'importe quel autre dossier. Ce que l'exemple du Mac de ton amie prouve sans contestation possible.​

- face à ces carences du service de partage > il est possible de restaurer l'« Âge d'Or » dans l'espace politique d'un OS. Ce > en modifiant la valeur de l'umask par défaut --> de manière à ce que les objets créés par les individus se trouvent soustraits a priori aux limitations de la « propriété privée ». Il est est possible a priori d'affecter à l'umask une valeur de 002 => qui ouvre des permissions totales d'appropriation sur les objets créés à tous les membres du groupe principal staff en plus de l'user-propriétaire de l'objet créé. Comme il est possible d'affecter à l'umask une valeur de 000 => qui ouvre des permissions totales d'appropriation sur les objets créés pour tous les membres de tous les groupes > en plus du créateur de l'objet.​

=> car l'umask est une valeur prise en compte par le serveur (le service des services) launchd (le launch_daemon ou INITializer) => lors déploiement a priori des processus de l'OS. Il est donc possible de faire prendre en charge par launchd une valeur d'umask qui fasse retourner l'« état de droit » de l'espace d'un OS => à l'« Âge d'Or » de l'« état de nature ». Je peux si tu le souhaites t'indiquer comme procéder à cette "révolution" des permissions.

 

[subsole]

J'admire beaucoup et me prosterne devant tant de connaissances , mais j'ai vomi

 

[litobar71]

la tirade de Cyrano n'a qu'à bien se tenir, saperlipopette !

 

[subsole]

BatChmod, pourrait il quelle chose ? Mais, je n'en sais rien ?

 

[mariol66]

Merci @macomaniac pour cette explication très détaillée

Hier j'ai reproduit sur mon Mac ce que souhaitait faire mon amie essayer de trouver une solution, je suis d'ailleurs tombé sur l'un de tes anciens posts qui expliquait ce problème. Je pensais vraiment que Mac OS permettait de faire cela facilement, ça me semblait logique.
Pensant que cela venait du fait que le User2 était en standard et non en admin, j'ai poussé mes recherches en créant une troisième session en User3 mais ce coup-ci en admin.

Je me retrouve donc avec
User1 > Admin
User2 > Standard
User3 > Admin

Là j'avoue ne pas avoir compris les résultats car en reproduisant ce qui a été fait au dessus j'ai les mêmes résultats entre User1 et User2, j'ai changé les permissions du dossier TOTO pour ajouter User3 en lecture et écriture.

Depuis le User3
J'ai pu ouvrir mon fichier modèle mais dès que je le copie ou modifie là encore, les permissions changent, normal après ton explication.
Le fichier "modèle" partagé est donc en début de test:
User1 > Lecture / écriture
User2 > Lecture / écriture
User3 > Lecture / écriture

Dès que ce fichier est dupliqué (ou modifié) les droits passent à:
User3 > Lecture / écriture
User2 > Lecture / écriture
User3 > Lecture / écriture

Ce qui fait que depuis le User1, pas de changement par rapport au test initial, il est en lecture seule une fois le fichier dupliqué ou modifié mais depuis le User2 je peux effectuer des modifications :bored: et idem, si je continue je peux
à nouveau changer le fichier créé par User3 depuis le User2 et le changer à nouveau depuis le User3 ce que je cherche à faire. Seulement le User1 est exclus de cette possibilité :dead: Logiquement, de ce que j'ai compris (ou pas ) ça ne devrait pas fonctionner non plus entre les User 2 et 3.

Toujours depuis le post dont tu avais participé, il était remonté une solution de contournement qui consiste à partitionner le HDD pour créer une partition de "partage" entre les utilisateurs (en cochant la case "Ignoré les autorisations de ce volume"), j'ai essayé cela semble fonctionné et je comptais faire cela sur le Mac de mon amie.

Après, @macomaniac, si tu as une solution pour adapter les permissions je suis preneur par contre je n'ai pas souvent accès au Mac de mon amie donc le retour risque d'être long. Normalement elle devrait me le laisser ce week-end ce qui me permettra aussi de tenter de régler un souci de Time Machine qui ne se lance pas sur son Mac (elle n'aurais pas les autorisations :eek: elle est pourtant admin mais dispose d'un autre compte admin dont elle n'a plus le mdp) et je voudrais en priorité lui faire une sauvegarde complète de son Mac car elle n'en a à ce jour aucune :eek:

 

[Membre supprimé 1060554]

Tu peux en effet --> effectuer un tout petit repartitionnement (non destructif) du volume de démarrage principal (du Mac de ton amie) => afin de créer un petit volume secondaire voué au partage. Appellons-le PARTAGE.

Cela fait > depuis la session ouverte de l'utilisateur admin > cocher dans une fenêtre d'informations du Finder ouverte sur le volume PARTAGE => l'option : "Ignorer les autorisations de ce volume". Cette action graphique édite un fichier de prédérence volinfodatabase dans l'OS avec l'effet suivant : le volume PARTAGE ne montera pas pour la session ouverte de tel ou tel utilisateur avec ses autorisations absolues (de volume parent et d'objets enfants) ; mais avec les autorisations relatives de l'utilisateur qui a ouvert la session > ce avec effet récursif sur tout le contenu du volume.

Chacun des 2 utilisateurs sera donc intronisé "user en lecture > écriture > exécution" du volume et de ses contenus - alternativement. C'est une solution élégante à la question d'un partage. Qui te permet de désactiver l'option de partage des fichiers dans l'OS de ton amie. C'est exactement ce qu'on attendrait de la part du service de partage sur un dossier dédié --> mais qui manifestement n'est pas le cas.

La solution de modifier l'umask d'utilisateur dans un OS est une solution extrêmement puissante et bien suivie par launchd après un redémarrage. Elle demande une configuration via le terminal néanmoins. Étant une solution universelle dans un OS > elle peut apparaître trop puissante pour les objectifs visés : permettre le partage local d'un espace déterminé. Donc le procédé du second volume est à préférer.

 

[mariol66]

Je vais donc rester sur la création d'un second volume qui je pense est mieux approprié pour mon amie et cela fera bien le taff. Pensant que l'option "partage de fichier" était liée avec le fait de partager un dossier entre utilisateurs (ce qui ne m'arrangeait pas dans le cas de mon amie), je me suis rendu compte qu'il pouvait être désactivé tout en gardant la possibilité de partager le dossier entre plusieurs sessions.

 

[Membre supprimé 1060554]

Il te suffira de copier le dossier /Users/Shared/TOTO at: /Volumes/PARTAGE/TOTO > puis de supprimer l'original du dossier Partagé. Ou même de copier simplement le contenu de TOTO => PARTAGE (sans dossier parent TOTO réceptacle) > l'espace total du volume PARTAGE étant considéré comme un dossier partagé entre les 2 utilisatrices.