1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Les Listes de contrôle d'accès (ACLs)




Les Listes de contrôle d'accès (ACLs) fournissent un grain plus fin, une façon plus souple de contrôler les permissions de fichiers : qui peut faire quoi, avec les fichiers. Dans Tiger, les ACLs viennent en supplément des permissions de fichiers traditionnelles d'Unix. Comme je n'ai jamais abordé les permissions de fichiers Unix dans un article sur Mac OS X auparavant, je voudrais le faire maintenant. Vous pouvez passer cette section si vous connaissez déjà.

Les permissions de fichiers Unix

Sous Unix, chaque fichier appartient à un utilisateur unique, et à un groupe unique. Les permissions de fichiers Unix contrôlent la possibilité de faire trois actions : lire un fichier, écrire sur un fichier, et exécuter un fichier. Pour un fichier donné, les permissions autorisent ou interdisent chacune de ces trois actions pour l'utilisateur qui possède le fichier, pour le groupe auquel le fichier appartient, et pour quiconque d'autre. Cela fait neuf permissions au total : lire, écrire, et exécuter pour le possesseur, le groupe et les autres.

Dans toute interface en ligne de commande (ICL) d'unix, les actions sont traditionnellement abrégées par les lettres "r", "w", "x". Le possesseur du fichier et son groupe sont aussi affichés. En voici un exemple :
listing

Le fichier ci-dessus appartient à l'utilisateur "John", et au groupe "Staff". Le premier caractère de la chaîne des permissions indique le type de fichier. C'est "-"pour les fichiers normaux (comme au dessus), "d" pour les répertoires (directories) "l" pour les liens symboliques, et ainsi de suite. L'exemple au dessus autorise la lecture, l'écriture et l'exécution pour le possesseur du fichier (john), le groupe (staff), et "n'importe qui d'autre". Voici un exemple plus restrictif
listing

Dans cet exemple, le possesseur (john) peut lire et écrire dans le fichier, le groupe staff ne peut que lire, et n'importe qui d'autre ne peut ni lire, ni écrire, ni exécuter. Le caractère "-" dans la chaîne des permissions indique l'absence du droit correspondant.

Ces permissions sont implémentées à l'aide d'un masque binaire, avec un bit pour chaque lettre dans la chaîne des permissions/ Chaque groupe de 3 bits de permissions peut être représenté par un nombre octal : 000 à 111 en binaire, ou 0 à 7 en décimal. Par exemple :
listing

Le fichier dans l'exemple ci-dessus est dans le "mode 640".

Il y a en fait au moins 3 bits supplémentaires de permissions qui précèdent les bits "utilisateur". Ces bits contrôlent les permissions d'héritage pour les répertoires (souvent propres au vendeur), et la possibilité pour un utilisateur qui exécute un fichier d'assumer l'identité du possesseur de fichier ou du groupe. Si bien que la chaîne complète du "mode" est "0640" dans l'exemple ci-dessus, en considérant qu'aucun des trois bits supplémentaires n'est défini.

Vous pouvez en savoir plus sur l'affichage et les modifications des permissions de fichiers en appelant "man ls" ou "man chmod" depuis le terminal.

Les listes de contrôle d'accès

Les permissions de fichiers Unix sont souples, mais il n'est pas difficile d'imaginer des scénarios dans lesquels elles ne fournissent pas un contrôle suffisant. Par exemple, cherchez à autoriser un utilisateur, Bob, à lire l'un de vos fichiers. Avec les permissions de fichiers traditionnelles d'Unix, la seule façon de procéder est de créer un nouveau groupe (disons, "amis") avec seulement deux personnes dedans : vous, et Bob. Il va falloir changer le groupe attaché au fichier en "amis", et donner à ce groupe la permission de lire.

C'est un peu compliqué, mais imaginez maintenant que vous voulez qu'un troisième utilisateur, Ray, puisse écrire dans le fichier, mais pas le lire. Et là, vous êtes coincé(e). Si vous mettez Ray dans le groupe "amis", il sera capable de lire le fichier. Si vous voulez un accès en écriture pour le groupe "amis", alors, Bob peut aussi écrire dans le fichier. Comme un fichier ne peut avoir qu'un seul possesseur et un seul groupe, vous ne pouvez rien faire. Le système des permissions de fichier Unix n'est pas assez souple pour satisfaire ce genre de besoins.

Pire, imaginez que vous voulez donner la possibilité d'effacer un fichier particulier à un groupe d'utilisateurs. Dans les permissions Unix classiques, il n'y a pas de permission "effacer" pour un seul fichier. La possibilité d'effacer un fichier est contrôlée par la permission "écriture" du répertoire parent. Le système des permissions Unix n'a pas un grain assez fin pour satisfaire ces besoins.

C'est là qu'interviennent les listes de contrôle d'accès. Une ACL est une liste ordonnée de règles qui contrôle les permissions de fichiers. Chaque règle spécifie trois choses : un acteur, une action, et si l'action est autorisée ou interdite. Une règle se nomme aussi ACE (Access Control Entry).

Pour déterminer s'il faut ou non autoriser une action, les règles sont prises en considération dans l'ordre. La première règle qui est applicable pour l'acteur courant et une action emporte la décision, et aucune autre règle n'est prise en compte. Si aucune des règles ne s'applique, alors, la décision est déterminée par les permissions de fichier traditionnelles d'Unix.

(En réalité, c'est un peu plus compliqué, dans le cas où des actions multiples sont demandées simultanément -ouvrir un fichier en lecture et en écriture, par exemple-. Mais la règle de base reste la même : les ACEs ont la préséance sur les permissions Unix).

Les ACLs peuvent être modifiés en ligne de commande avec la commande chmod (voyez "man chmod" pour plus de détails), ou avec l'application Workgroup Manager pour Mac OS X Server.

Pour que les ACLs fonctionnent, elles doivent être autorisées sur un volume donné. L'application Workgroup Manager dans Mac OS X 10.4 server peut le faire, mais cette application n'est pas incluse dans la version normale (non serveur) de Tiger. Il y a une solution en ligne de commande, toutefois. La commande suivante va autoriser les ACLs sur le volume de démarrage :
listing

Voici une brève démonstration des ACLs. Commençons avec un fichier dont le nom est "file".
listing

Tel qu'il est, seul l'utilisateur john peut lire et écrire dans le fichier. Revenons maintenant aux exemples précédents où les permissions Unix ont été insuffisantes. Avec les ACLs, cela devient tout simple.

• Autoriser un seul utilisateur, Bob, à lire un de vos fichiers
listing

• Autoriser Ray à écrire dans le fichier, mais pas à le lire
listing

• Autoriser un groupe d'utilisateur (disons, "staff") à effacer le fichier
listing

Vous pouvez utiliser la nouvelle option "-e" dans la commande "ls" pour afficher les ACLs d'un fichier depuis la ligne de commande.
listing

Notez encore une fois que les permissions de fichiers Unix n'ont pas changé. Si Bob cherche à lire, si Ray cherche à écrire, ou si n'importe qui du groupe "staff" cherche à effacer le fichier, les permissions Unix ne seront pas consultées du tout.

La commande chmod peut ajouter ou supprimer des ACEs, et les insérer dans des positions spécifiques dans les ACLs. Rappelez-vous, c'est très important que les ACLs soient des listes ordonnées ; la première règle qui s'applique est gagnante.

J'ai mentionné la granularité plus fine des ACLs. Cette copie d'écran de l'application Workgroup Manager du serveur Tiger vous donne une idée de ce qui est possible :

WGM ACL panel

Le panneau ACL de Workgroup Manager (serveur Tiger seulement).

Rappelez-vous que chaque ACE peut autoriser ou interdire chacune de ces actions à n'importe quel utilisateur ou groupe, et qu'il peut y avoir un nombre illimité d'ACEs par fichier (dans l'absolu, si ce n'est en pratique).

Les ACLs supportent "l'héritage statique". Cela signifie que l'ACL initial d'un fichier nouvellement créé peut être déterminé par les ACLs d'un ou de plusieurs de ses répertoires parents. Cet héritage intervient une seule fois, au moment où le fichier est créé. Si les ACLs des parents changent après coup, les enfants n'héritent pas de ces changements.

La nature instantanée de cet héritage est ce qui le rend "statique". Comme vous pouvez l'imaginer, le système opposé, "l'héritage dynamique", est très difficile à gérer, avec des changements sur un seul répertoire susceptibles de se propager à tous les fichiers et répertoires en dessous de lui. Apple a fait à coup sûr le bon choix. (Comme le souligne un lecteur, le support des deux formes d'héritage aurait été encore mieux. Mais je choisirais encore le mode "statique" comme mode par défaut).

Tiger s'affranchit aussi de la limite de 16 groupes de Panther et des précédentes versions de Mac OS X. Maintenant, un utilisateur peut appartenir à un nombre quelconque de groupes. Ce qui est plus intéressant, les groupes peuvent être imbriqués, ce qui crée une hiérarchie de groupes. Par exemple, le groupe "staff" peut rassembler tous les employés, alors que le groupe "gestionnaires" peut être un sous-ensemble de "staff", et que les "dirigeants" peut être un sous-ensemble de "gestionnaires", et ainsi de suite.

Définir un ACE comme "staff allow read" va autoriser "staff", "gestionnaires", et "dirigeants" à lire. Un ACE comme "gestionnaires allow write" permettra aux "gestionnaires" et aux "dirigeants" d'écrire, mais pas aux membres de "staff". Voilà l'idée.

Pas besoin de dire que cela représente un énorme progrès pour tous ceux qui ont à administrer un serveur Mac OS X. Les ACLs permettent de coller beaucoup plus finement à la hiérarchie d'une organisation.

Pour résumer sur les ACLs

Les ACLs existent sous de multiples formes dans de nombreux systèmes d'exploitation depuis de nombreuses années. Dans l'affaire, Tiger ne fait que rattraper le peloton. Même Mac OS Classique avait quelques possibilités de partage des fichiers qui allaient au delà des permissions de fichier traditionnelles d'Unix.

L'addition des ACLs à Tiger, a été manifestement motivée par l'écart entre les permissions Unix et le modèle de permissions Active Directory de Windows. Avec Tiger, Mac OS X peut enfin servir des fichiers (et exister comme partenaire entier) sur un réseau Windows.

Avant d'abandonner ce sujet, je voudrais que les lecteurs se représentent ceci : où, exactement, Tiger stocke-t-il touts ces informations nouvelles de permissions de fichier ? Où est la "liste des contrôles d'accès" de chaque fichier ?

Et bien, où sont stockées les permissions de fichiers Unix ? C'est dans les structures de méta-données du système de fichier, bien sûr, avec le nom du fichier, la date de modification, et ainsi de suite. Les ACLs sont stockées au même endroit. Mais plutôt que d'être forcé de changer le format de volume HFS+ d'une façon incompatible, pour rajouter ces nouvelles méta-données (ce qui aurait obligé à reformater le volume pour utiliser les ACLs), les ACLs sont stockées (vous l'avez deviné) dans les attributs étendus des volumes HFS +.

(Les attributs ACL sont apparemment masqués par les APIs d'attributs étendus sous Tiger, si bien que vous ne pourrez pas les voir avec le programme xattr. Il est vraisemblable qu'elle utilisent aussi le préfixe réservé "system." de l'espace de noms pour leurs noms d'attributs.)

Cela n'est que l'accomplissement de la promesse d'une caractéristique un peu ésotérique, réclamée depuis longtemps : "des méta-données arbitrairement extensibles pour le système de fichiers". Pour les gens qui ne pouvaient pas voir au delà de ce qui existe, la possibilité d'associer des éléments de données arbitraires à n'importe quel fichier ou répertoire semblait intéressant, peut-être, mais largement sans objet.

Il apparaît qu'Apple elle-même était dans ce camp, à l'aube de l'ère Mac OS X. Avec Tiger, Apple a commencé à faire bouger le navire. Même les partisans les plus radicaux de la campagne pour de meilleures méta-données du système de fichiers, doivent admettre que c'est quand même bien de récupérer toutes les caractéristiques des ACLs sans avoir à reformater le disque.

La barre latérale des méta-données

Dans une tirade (heureusement rarement lue) sur le futur de Mac OS X écrite le 7 décembre 2001, je me moquais des opposants à une amélioration importante des méta-données du système de fichiers, et mettais en garde sur le risque qu'Apple ne prenne pas part à ce futur inévitable, qu'elle ne se réveille pas.

Ne vous y trompez pas, le futur de l'informatique sera absolument sans intérêt, avec ces méta-données haîssables, de complexité croissante, qui empêchent la compatibilité, entravent les performances, avec ou sans Apple. Douter de cela, c'est nier toute l'histoire de l'informatique, c'est penser que ceci, d'une certaine façon, agira différemment de toutes les autres technologies qui ont éclos avant elles.

Avant de revenir sur cet article, je veux juste exprimer mon soulagement que les sentiments anti-méta-données exprimés publiquement par beaucoup de gens, et apparemment partagés par Apple à l'aube de Mac OS X, aient été sagement abandonnés.

Steve Jobs a visité le PARC de Xerox en 1979. Dans un interview en 1995, avant que Jobs ne revienne chez Apple, il avait dit ceci, au sujet de sa première impression de l'interface utilisateur graphique au PARC en 1979 .

Au bout de 10 minutes, il m'apparut évident que tous les ordinateurs aimeraient cela un jour

Beaucoup d'employés chez Apple étaient déjà dans la course du GUI avant 1979, et Jobs visita le PARC largement à cause de leur demande. Après la visite, il vit la lumière, et le reste, c'est de l'histoire.

Je soupçonne que rien d'aussi dramatique ou significatif n'est intervenu dans le cas des méta-données du système de fichiers, mais je ne crois pas que ce soit exagéré d'imaginer une situation un peu similaire. Il n'est pas difficile de deviner de quel côté chez Apple, des employés comme Dominic Giampaolo ont penché, mais le joker a toujours été dans les mains de Jobs. Convainquez-le des mérites de vos idées, et vous avez les mains libres.

En ce moment, je ne suis pas vraiment sûr que Jobs est monté dans le wagon des méta-données du système de fichiers. En fait, je ne suis pas sûr qu'il se soucie, ni même qu'il soit au courant de la difficulté au niveau de l'implantation. Son travail est de voir les choses de haut. Les gens avisés qu'il emploie sont sensés résoudre les détails techniques.

Deux choses sont rendues claires par Tiger. La première, le consensus des conseillers techniques de Jobs a penché clairement en faveur du camp pro-méta-données. Depuis combien de temps, et jusqu'où est allé le penchant, est laissé à votre appréciation. La seconde, c'est que Jobs est assez convaincu des mérites de cette approche pour ne pas, en fin de compte, s'être opposé aux efforts pour améliorer cet aspect de Mac OS X.

Cela peut ressembler à une condamnation avec une louange bien maigre, mais je suis vraiment content de voir enfin un signe extérieur d'un tournant que je ressens comme une étape très importante. Les méta-données constituent le futur, et je me rejouis de voir qu'Apple a décidé d'enfourcher le dada.

Mais attendez, il y plus...