Pour la rentrée, je vous propose un article plus long que la moyenne, et qui aborde les problématiques de gestion des permissions sous AFP. Car sous Mac OS X Server 10.5, j’ai constaté que de nombreux administrateurs (moi y compris, avant de me pencher vraiment sur le sujet il y a quelques mois de cela) ont eu du mal avec le fonctionnement des permissions. Cas classique :
• Un utilisateur A appartenant à un groupe (appelons-le Travail) crée un fichier Toto.doc.
• Un administrateur a créé un point de partage “Boulot” sur un serveur AFP sous 10.5. Il lui a attribué les autorisations POSIX suivantes :
- Possesseur : lui-même, en lecture/écriture ;
- Groupe : Travail, en lecture et écriture ;
- Autres : lecture seule
• L’utilisateur A copie son fichier toto.doc sur le point de partage, via AFP ;
• L’utilisateur B, appartenant aussi au groupe Travail, essaie de modifier le fichier toto.doc.
Et là… impossible ! Le système lui indique qu’il n’a pas les autorisations suffisantes pour modifier le fichier. Pourtant, en toute logique, le fichier devrait avoir des permissions en lecture/écriture pour les membres du groupe travail… sauf que ce n’est pas le cas, le groupe attribué au fichier ne disposant que de la lecture seule. Comment est-ce possible ? Pourquoi les autorisations sont attribuées de façon incorrecte au fichier ?
On pourrait croire qu’il s’agit d’un bug. Pourtant, le comportement est exactement celui attendu. Le problème est plus insidieux, et la faute en incombe aux… ACLs. Mais l’explication est particulièrement tordue, et pour la comprendre, il faut remonter de quelques années en arrière…
Avant Mac OS X Server 10.2.4
Avant l’arrivée de Jaguar Server dans sa version 10.2.4, le comportement du partage de fichier respectait les autorisations Posix. Cela signifie que les autorisations d’un fichier copié sur un serveur étaient les mêmes que celles du fichier source, c’est à dire que le masque appliqué est identique entre le fichier source et la copie sur le serveur. En pratique, un fichier dont le groupe est en lecture seule sur la machine cliente restera en lecture seule s’il est copié sur le serveur.
Mais cela posait de nombreux problèmes pour les utilisateurs et les administrateurs informatiques, car cela empêchait le transfert des informations entre utilisateurs. Pourquoi ? Parce que le masque appliqué par défaut à tous les fichiers créés sur Mac OS X est 022, ce qui fait qu’un fichier est toujours en lecture/écriture pour son possesseur, mais en lecture seule pour son groupe.
Quand on copie un fichier sur le serveur, c’est ce masque qui est conservé. Si chaque fichier généré sous Mac OS X se voyait attribué un masque en lecture/écriture pour le groupe (002), il n’y aurait aucun souci, le masque étant transféré sur le serveur, et les autorisations seraient alors correctes.
De Mac OS X 10.2.4 à 10.4 : l’héritage des permissions
Comme modifier le comportement de Mac OS X impliquait des soucis de sécurité un peu plus larges, Apple a donc modifié le client et le service AFP en 10.2.4 pour permettre l’héritage des permissions, comme expliqué dans l’article 107623 de la Knowledge Base. Ainsi, un fichier récupère les permissions d’accès du groupe associé au dossier où il est placé. Il suffit de cocher la case Recevoir les autorisations des parents, et hop, on est tranquille.
C’est ce que l’on attend en fait la plupart du temps, et c’était d’ailleurs le comportement de ce bon vieil AppleShare IP ou du partage de fichiers personnel sous Mac OS 9. Et finalement, ça marchait très bien. Sauf qu’une des grosses nouveautés de Mac OS X Server 10.4 allait imposer un nouveau changement, très attendu mais assez pernicieux.
Mac OS X Server 10.4 : bienvenue aux ACL !
Les ACL (Access Control Lists, appelées aussi listes de contrôle d’accès ou LCA) ont apporté une grande souplesse d’utilisation dans la gestion des permissions. Cependant, sous Mac OS X Server 10.4, il faut explicitement activer les ACL pour chaque volume.
Si les ACL ne sont pas actives, les permissions d’un partage peuvent toujours être attribuées façon POSIX ou via l’héritage des permissions. Mais si elles sont actives, l’héritage ne fonctionne plus, d’ailleurs la case ad hoc est désactivée. Et devinez quoi ? Dans ce cas, c’est l’attribution des autorisations façon POSIX qui prend le relais par défaut ! Il faut alors éventuellement rajouter des autorisations via des ACL pour que les différents utilisateurs puissent modifier le fichier.
Mac OS X Server 10.5 : ACL obligatoires
Après toute cette description, vous comprendrez peut-être ce qui se passe sous Mac OS X Server 10.5 : les ACL sont systématiquement actives par défaut et ne peuvent pas être désactivées (il n’y a aucune case qui le permette dans Server Admin ou ailleurs). Ce qui implique que par défaut, c’est toujours le comportement POSIX qui prime. Et du coup, il est relativement simple de corriger le souci et permettre à nos deux utilisateurs de s’échanger leurs fichiers : il suffit de rajouter le groupe en lecture/écriture… sous forme d’entrée dans les ACL. C’est à dire, dans Server Admin, de glisser le groupe Travail dans la ligne LCA, et non pas la ligne Groupe en POSIX, et lui attribuer les autorisations en lecture/écriture.
Mais pourquoi tant de confusion ? D’abord, l’interface de Server Admin a souffert durant quelques versions d’un oubli gênant : jusqu’à Mac OS X Server 10.5.2 inclus, la case d’héritage des permissions du parent était toujours visible dans l’interface graphique, quand bien même elle n’avait aucun effet. Cela a été corrigé en 10.5.3, les options d’héritage ayant disparu :
La faute aussi à la documentation de Mac OS X Server, qui manque probablement de clarté quand à la différence entre la gestion POSIX et les ACL, et leur influence sur un modèle de partage de fichiers assez courant. Une grande partie des problèmes vient également du masque par défaut appliqué aux fichiers sous Mac OS X : si chaque groupe avait par défaut l’accès en lecture et écriture sur tout nouveau fichier généré, on aurait beaucoup moins de soucis…
Enfin, une partie de ce comportement vient de la difficulté à concevoir un modèle où la sécurité, les origines UNIX de Mac OS X et les besoins des utilisateurs d’un système graphique puissent coexister paisiblement. Et finalement, quand on comprend le fonctionnement de Mac OS X, on comprend aussi que l’héritage des permissions était un patch qu’il était nécessaire de supprimer, les ACL étant gérées au niveau du noyau de Mac OS X et non pas du seul client AFP.
Vous savez donc désormais comment agir : ne vous occupez plus spécialement des autorisations POSIX, et concentrez-vous sur les ACL. Vous pourrez ainsi gérer vos autorisations du partage de fichiers plus efficacement et de façon bien plus souple. Au passage, lisez la documentation de Mac OS X Server 10.5, en particulier celle-ci (PDF, 1,4 Mo).
N.B. : ceux qui ont installé leur serveur 10.5 en mode standard (et non pas avancé) n’ont même pas souffert de ce problème. Pourquoi ? Parce que dans l’interface des Préférences Serveur, la notion de POSIX n’est pas représentée : en réalité, tout est géré via les ACL…
N.B.2 : une autre solution aurait pu consister à modifier le masque global appliqué aux fichiers, mais il faut le faire aussi sur chaque poste client… Voir ce document pour la méthode.
Derniers commentaires
RSS