Tag Archive for ACL

Conférence : Voyage au pays des ACL

J’ai eu le plaisir d’être invité il y a quelques semaines à la première conférence MacSysBrain des administrateurs Mac francophones. J’y ai présenté une conférence de 20 mn environ, que vous pouvez désormais télécharger par ici. Elle est consacrée aux fameuses Listes de Contrôles d’Accès (les ACLs) et leur intégration dans Mac OS X Server. Vous pourrez également découvrir avant ma conf une présentation de Yoann Gini sur la fameuse technologie Wide Area Bonjour, alors que Franck Lefèbre s’est attaqué à SSH.

Bon visionnage !

Time Machine Erreur 11 : et pourquoi pas les ACL ?

Je viens de tomber sur un cas étrange : un serveur qui refuse de sauvegarder correctement avec Time Machine, en déclenchant des erreurs de ce type à tort-la-rigaud tire larigot :

41) SrcErr:NO Copying /Groups/xxxxxx/blahblah/pouet/DossierTruc to /Volumes/Copies de sauvegarde Time machine/Backups.backupdb/Monserveur/2009-11-13-005451.inProgress/ED94403D-4B1F-42A1-9DCF-7A36836BABA2/Groups/xxxxxx/blahblah/pouet/DossierTruc
Nov 13 01:20:33 serveur com.apple.backupd[57561]: Copied 526 files (292.7 MB) from volume Serveur.
Nov 13 01:20:33 serveur com.apple.backupd[57561]: Copy stage failed with error:11
Nov 13 01:20:39 serveur com.apple.backupd[57561]: Backup failed with error: 11

Cas intéressant : ce plantage surgit toujours au même endroit, et si on exclut le dossier coupable des sauvegardes, le bug se répète quelques minutes plus tard au même endroit. Pourtant les fichiers incriminés semblaient en bon état… Et le scénario se répète sur deux serveurs de sauvegarde différents… Hmmmmm.

Après pas mal de recherches, il semble que le bug soit lié à un nombre d’ACL trop important sur les dossiers ou fichiers incriminés. En supprimant les entrées surnuméraires de la liste des autorisations (avec Server admin par exemple) et en particulier des ACL, il semble que Time Machine n’échoue plus sur la sauvegarde.

Pensez-y donc : si votre sauvegarde avec Time Machine vous semble chancelante, pensez à vérifier les ACL de vos dossiers et réduisez-les au maximum.

Régler les problèmes de permission avec AFP sous Leopard Server

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 :

    1. Possesseur : lui-même, en lecture/écriture ;
    2. Groupe : Travail, en lecture et écriture ;
    3. 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.

Autorisations des parents

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.

Autorisations sous 10.5

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 :

Depuis Mac OS X Server 10.5.3, l\'option d\'héritage des permissions a 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.