10.11 El Capitan Gestion sessions

[Vladimok]

Bonjour,

Je viens de creer une session sur mon mac.
Mon soucis est que toutes les applications sont visibles et lancables d'un session à une autre.
Comment évité cela ? et ne choisir que les applications visibles d'une session à une autre ?

Merci

 

[Moonwalker]

So what ? C'est le principe de fonctionnement d'un système unix multi-sessions.

Pour limiter l'utilisateur il te faut employer le contrôle parental.

Maintenant, tu peux te créer sur ta session un répertoire ~/Applications dans lequel tu places les applications que tu entends te réserver. Mais attention, il faut lui appliquer les mêmes droits que les répertoires ~/Documents ou ~/Images, à savoir lecture et écriture interdite pour everyone.

 

[Vladimok]

J'ai 2 sessions A et B (B nouvelle session)
Il faut que je deplace toutes les applications de la session A, dans un nouveau repertoire application ?

 

[Moonwalker]

J'ai 2 sessions A et B (B nouvelle session)
Il faut que je deplace toutes les applications de la session A, dans un nouveau repertoire application ?

Je crois qu'une petite révision de la hiérarchie des répertoires sous macOS s'impose :
http://rocbo.net/macosX-5/hierarchie.html

/Applications est un répertoire commun à toutes les sessions. Il est normal que A et B ont accès aux applications qui s'y trouvent (par exemple Safari, Aperçu, Calendrier, Contact, etc).

Si tu installes des applications dans ce répertoire, elles sont également d'un usage commun à toutes les comptes A, B ou C créés sur ce système.

Ne pas toucher aux applications du système ni aux applications "lourdes" (M$ Office, Adobe, etc).


Tu peux créer un répertoire Applications qui soit uniquement sur un compte et réservé à son usage.

On le notera par exemple /Macintosh HD/Utilisateurs/A/Applications

Tu peux y déposer des applications de type "simple", qui s'installent par drag&drop (par exemple Firefox, Opera, etc).

Si tu limites les droits d'accès à ce répertoire en interdisant la lecture/écriture à everyone et en supprimant groupe, à l'image des droits sur ~/Documents, l'utilisateur du compte B ne pourra pas lancer cette application dont il n'aura même pas connaissance.


La question ici est de savoir quelle est vraiment ton problème ?

S'il s'agit de l'accès par B à /Applications, c'est parfaitement normal. Et si tu veux restreindre l'usage de B de ces applications il faut utiliser le Contrôle Parental.

S'il s'agit de l'accès qu'aurait B des applications situées dans /Macintosh HD/Utilisateurs/A/Applications, il faut définir les droits de ce répertoire Applications conformément aux répertoires ~/Images et ~/Documents.

 

[Membre supprimé 1060554]

La question ici est de savoir quel est vraiment ton problème ?

Hé oui !

Lors de la création de fils sur les forums > tout se passe souvent comme si la règle tacite était : « ne me demandez pas pourquoi » (je demande ce que je demande) - mais procurez-moi une solution technique (sans qu'il soit besoin de clarifier la raison de ma demande).

Mais l'examen des raisons est prépondérant. Comme les philosophes classiques avaient la candeur de le relever : il y a des raisons qui ne sont pas "raisonnables" ; ou encore : il y a des raisons qui sont "embrouillées" etc. Clarifier les raisons d'une demande - c'est ce qui permet d'ajuster une réponse.

Vladimok (qui connaît trop bien compère maco pour s'offusquer de ses malices

) pourrait décrire avec quelques détails à qui est destiné le compte B fraîchement créé dans son OS et par là ce qui le conduit à souhaiter limiter l'accès à des applications de ce compte - parce que ce n'est pas évident en soi.

Le second compte est-il admin ou standard ? Destiné à un enfant > un conjoint > un avatar de soi ? Quelles sortes d'applications dans ce contexte auraient à être interdites d'accès : des applications Apple ou de tierce partie ? Capables d'agir sur le Système (comme le «Terminal») ou orientées internet (comme un navigateur) ? - car à supposer que l'utilisateur du second compte soit un autre qui ait des droits admin et la disposition du «Terminal» --> rien ne peut lui être interdit dans l'absolu à partir de là - sinon par son ignorance de ce qui est possible. Il suffirait même de donner accès à son Mac à une tierce personne qui n'aurait qu'une session Invité mais la possibilité de se logger en Single User > pour que tout soit possible encore théoriquement parlant.

 

[Vladimok]

La session B est destiné à ma femme, qui n'y connait pas grand chose en info. et je ne souhaite pas qu'elle fasse de la casse dans mes applis pro. Elle n'a besoin que de quelques appli standard.

 

[Moonwalker]

La session B est destiné à ma femme, qui n'y connait pas grand chose en info. et je ne souhaite pas qu'elle fasse de la casse dans mes applis pro. Elle n'a besoin que de quelques appli standard.

Tu n'as pas besoin de l'empêcher d'accéder aux applications. Si tu créés B comme compte standard (c'est-à-dire non administrateur), elle n'aura pas la possibilité de modifier /Applications. Cela suffit largement.

Elle ne peut pas faire de la casse dans tes applications professionnelles.

Les réglages des applications tels que tu les as définis depuis ta session A sont propres à cette session. Lorsque par exemple elle ouvre Safari pour la première fois, elle aura la configuration par défaut de Safari, pas tes préférences et signets, idem pour Mail, Contacts, Calendrier. C'est la même chose pour Microsoft Office, LibreOffice, Adobe Photoshop et autres.

En multi-sessions chaque utilisateur a ses propres préférences enregistrées dans la bibliothèque de compte (celle qui est cachée). Ce sont ces préférences qui définissent le comportement des applications sur cette session, et pas sur une autre.

Seuls les administrateurs peuvent agir sur /Applications, et encore, pas sur tout depuis l'introduction du SIP.

 

[Vladimok]

D'accord, donc la session B en standard.
Mais si je desire qu'elle n'ouvre pas Photoshop par exemple, il y a une possibilité ?

 

[Moonwalker]

D'accord, donc la session B en standard.
Mais si je desire qu'elle n'ouvre pas Photoshop par exemple, il y a une possibilité ?

Le Contrôle Parental.

 

[Membre supprimé 1060554]

Le compte B en statut standard interdira de supprimer (par exemple) des applications du répertoire Applications (car pour cela il faut être admin). Mais pas de lancer des applications.

Si tu veux restreindre la permission de lancer certaines applications > tu as 2 procédés possibles :

- a) le contrôle parental --> dans le panneau des Utilisateurs et groupes > sélectionner le nom du compte B > cocher la case "Activer le contrôle parental" > presser le bouton "Ouvrir les contrôles parentaux" > onglet "Applications" > cocher la case "Limiter les applications de ce Mac" => par défaut > la liste des applications autorisées va se borner aux logiciels Apple natifs > et tu peux rajouter manuellement des applications tierces autorisées.

----------

- b) une entrée d'ACL. Chaque objet de l'OS est flanqué d'un attribut invisible qui est son ACL (Access Control List) = liste de contrôle d'entrée. Dans cette liste, vide par défaut, il est possible de créer une (ou plus d'une) entrée spéciale dite ACE (Access Control Entry) > spéficiant (par exemple) que l'utilisateur de tel nom est interdit de telle opération sur l'objet correspondant.

Suppose que le nom de compte de l'utilisatrice du compte B soit nana. Comme je n'utilise pas Photoshop > je ne sais pas exactement quel est l'intitulé de cette application > je vais supposer pour l'exemple encore que c'est «Photoshop.app».

Il suffit de passer dans le «Terminal» une commande de la forme :

sudo chmod +a "nana deny execute" /Applications/Photoshop.app

et hop ! tu as une ACE invisible sur le paquetage de Photoshop qui interdit spécifiquement à nana de lancer Photoshop (vicieux, non ?).

Pour faciliter la commande > tu te contentes de saisir d'abord :

sudo chmod +a "nana deny execute"

(où bien entendu tu remplaces mon "nana" par le nom de compte de ton utilisatrice) > tu sautes un espace > et tu fais un glisser-déposer direct de l'application Photoshop dans la fenêtre du «Terminal» > ce qui renseigne automatiquement le chemin au logiciel et son nom exact. Tu valides en pressant la touche "Entrée" du clavier > une demande de password s'affiche (commande sudo) --> tu tapes ton mot-de-passe de session admin à l'aveugle - aucune caractère ne se montrant à la frappe - et derechef tu valides.

Si tu veux interdire de lancement toute une série d'applications > tu tapes l'équivalent de la partie constante de la commande :

sudo chmod +a "nana deny execute"

> tu sautes un espace > et tu fais autant de glisser-déposer d'applications que tu veux (un espace séparateur se crée automatiquement en sortie de chaque glisser-déposer) => ainsi la même commande en facteur commun va créer une ACE restrictive au détriment de nana dans la liste d'ACL de chacune des applications.​

 

[Vladimok]

et si je veux faire l'opération inverse ?

 

[Membre supprimé 1060554]

Tu repasses la même commande modèle > en inversant seulement le signe initial de l'option --> de +a (ajout d'une ACE) à -a (soustraction d'une ACE) > l'ACE étant désignée à la suite par la même formule exacte qui avait servie à la créer - dans notre exemple "nana deny execute".

Donc supposons que la commande initiale ait été -->

sudo chmod +a "nana deny execute" /Applications/Photoshop.app

tu passes la commande de suppression :

sudo chmod -a "nana deny execute" /Applications/Photoshop.app

(dans ces commandes > l'utilitaire appelé est chmod = change_mode : changer le mode des permissions)

----------

Mais tu aimerais peut-être bien savoir si ça a marché (dans un sens ou dans un autre) ? La commande qui te renseigne (toujours dans mon exemple) est :

ls -led /Applications/Photoshop

Après que tu aies passé la commande initiale d'ajout d'une ACE restrictive > tu devrais avoir un retour du type :

drwxr-xr-x  vladimok  admin  /Applications/Photoshop.app
  0: user:nana deny search

(l'interdiction d'aller chercher l'exécutable de «Photoshop» impliquant l'interdiction de l'exécuter).

Après que tu l'aies supprimé par la commande inverse > tu devrais avoir un retour du type :

drwxr-xr-x  vladimok  admin  /Applications/Photoshop.app

où tu vois qu'il n'y a pas d'entrée d'ACL > ces entrées (ou ACE) étant toujours mentionnées en-dessous en alinéas > avec des numéros correspondant à leur rang dans l'ACL > le 1er rang étant 0.

[ L'utilitaire ls (list : lister) est appelé ici > avec les 3 options -led = l (long_format : le retour va être bavard) > e (entry = ACE) > d (directory : lister les répertoires comme des fichiers pleins) > et au final l'adresse de l'objet-cible. ]

----------

Mais au fait > ça te fatigue de passer 2 commandes chaque fois ? - alors tu peux les combiner en une seule chaque fois > avec un ; servant de charnière > ce qui donne :

sudo chmod +a "nana deny execute" /Applications/Photoshop.app ; ls -led /Applications/Photoshop

sudo chmod -a "nana deny execute" /Applications/Photoshop.app ; ls -led /Applications/Photoshop

=> en conséquence : l'ACE est inscrite ou supprimée dans l'ACL de «Photoshop» et les permissions (avec l'ACE s'il y a une entrée) de l'application te sont retournées illico.

----------

De manière globale > tu peux passer une commande résiliatrice de toute entrée d'ACL trouvée à l'adresse indiquée (remise à zéro) en introduisant -N (Negation) en option massive de chmod > ce qui peut donner :

sudo chmod -N /Applications/*

(tous les contenus du répertoire Applications - désignés par l' * - vont être purgés d'ACE de leurs ACL)
ou simplement :

sudo chmod -N /Applications/Photoshop.app

si tu préfères être sélectif.

(NB. comme les ACE n'ont été attribuées au départ qu'au paquetage de l'application (non récursivement) > il n'y a donc pas besoin d'ajouter une option récursive -R à chmod pour leur suppression.)

La dernière commande avec l'option -N apparaît redondante de celle avec l'option -a précédente > mais dans les faits > comme il pourrait y avoir de nombreuses ACE dans l'ACL de tel objet > en tel cas l'option -N les supprime toutes (= vide la liste ACL de l'objet de toutes ses entrées ACE) > alors que l'option -a ne supprime qu'une ACE de la liste ACL (l'entrée ré-identifiée par sa formule).

 

[Moonwalker]

Tout cela est intéressant mais représente quand même beaucoup de travail pour pas grand chose.

Je le répète : aucun risque de rien "casser" depuis une session standard. Elle n'a simplement pas les droits pour modifier quoique ce soit en dehors de sa propre session. Même les Préférences Système sont limitées.

 

[Vladimok]

Merci pour vos réponses