Gestion des ACLs (Access Control Lists - Listes de Contrôle d’Accès)

Objectif :

NTFS (système de fichier de Windows NT) offre, nativement, plus de possibilité dans les contrôles d’accès aux fichiers que Ext3. Pour remédier à cela, il faut configurer la gestion des ACLs au niveau :
 du Noyau
 du système de fichiers
 de Samba

Noyau :

Le noyau 2.6 intègre une gestion des ACLs. Il faut recompiler le noyau pour le prendre en compte. Sinon, il existe des rustines pour d’autres noyaux, à vous de voir !

Pour cela installer les sources du noyau 2.6 dans /usr/src puis créer un lien symbolique :
cd /usr/src
ln -s linux-2.6.1 linux
cd linux
make xconfig

valider les options dans la section File Systems

CONFIG_EXT2_FS_XATTR=y (Ext2 extended attributes)
CONFIG_EXT2_FS_POSIX_ACL=y (Ext2 POSIX Access Control Lists)
CONFIG_EXT3_FS_XATTR=y (Ext3 extended attributes)
CONFIG_EXT3_FS_POSIX_ACL=y (Ext3 POSIX Access Control Lists)
CONFIG_FS_POSIX_ACL=y (POSIX Access Control Lists)

L’option CONFIG_FS_POSIX_ACL est une option cachée, automatiquement validée si l’on décide d’utiliser les ACLs dans Ext2 ou Ext3 (ça a été mon cas avec make xconfig - à vérifier).

Pour éviter l’écran noir au démarrage du noyau, valider l’option suivante :
Device Drivers -> Graphics Support -> Console display driver support -> Video mode selection support

Mon système de fichier racine est ext3, par défaut ext3 est chargé en module, je l’inclue dans le noyau pour pouvoir booter dessus.
make bzImage modules
make modules_install install

Et redémarrer sur le nouveau noyau.

Système de fichiers :

Créer une partition ext3 gérant les ACLs :
installer ACL, libacl1 et libattr1

syntaxe : mount $device $chemin -t ext3 -o acl

ex : mount /dev/hda9 /mnt/serveur -t ext3 -o acl

Pour éviter de le taper après chaques démarrages, modifier votre fichier /etc/fstab :

/dev/hda9 /mnt/serveur ext3 acl 1 2

Samba :

Info : Le package Samba-server fourni avec Mandrake 9.2 est déjà compilé avec le support des ACLs, je ne sais pas pour les autres distributions ce qu’il en ait. Sinon, voici la procédure à suivre :

Récuperer les sources de samba.
Installer les dépendances : pam-devel , autoconf , readline-devel , libldap2-devel , popt-devel , libacl-devel , libcups-devel
J’utilise actuellement samba2.2.8a
Se positionner dans le répertoire source puis :
./configure —host=i386-linux —build=i386-linux —with-fhs —prefix=/usr/local/ —sysconfdir=/etc —with-privatedir=/etc/samba —localstatedir=/var —with-netatalk —with-smbmount —with-pam —with-syslog —with-sambabook —with-utmp —with-read-line —with-pam_smbpass —with-libsmb-client —with-winbind —with-msdfs —with-acl-support

ne pas oublier —with-acl-support (sinon ça ne sert à rien de se donner autant de mal ;-) )
make
make install (en tant que root)

Puis lancement des deamons :
 /usr/local/sbin/smbd -D
 /usr/local/sbin/nmbd -D

Vérification :

Vérifier que tout fonctionne sur la partition ext3 avec ACL à l’aide de deux commandes :
 getfacl visualisation des droits du fichier ou du répertoire
ex : getfacl mon_dossier

 setfacl
setfacl -m/-x u:utilisateur:permissions fichier(s)
setfacl -m/-x g:groupe:permissions fichier(s)
setfacl -m/-x o:permissions fichier(s)

ex : donner les droits en lecture/ecriture/listage au groupe adella sur le répertoire public.

 on créé le répertoire public :
[root@villou serveur]# mkdir public

 affection du groupe
[root@villou serveur]# chgrp adm public

On change le mode sans oublier de mettre le SGID à 1 (tout nouveau fichier dans le répertoire public aura le groupe adm) ainsi que le sticky bit (ou permanent) pour autoriser seulement le propriétaire à effacer son fichier.

[root@villou serveur]# chmod u=rwx,g=rwxs,o=rxt public

Vérifions les droits :
[root@villou serveur]# ll
total 1
drwxrwsr-t 2 root adm 1024 mar 1 21:01 public/
[root@villou serveur]# getfacl public/
# file: public
# owner: root
# group: adm
user::rwx
group::rwx
other::r-x

Donc, si je me connecte en tant que utilisateur1 (groupe adella), je ne peux pas créer et modifier des fichiers dans le répertoire public :
[utilisateur1@villou serveur]$ cat >> ./public/test
bash: ./public/test: Permission denied

Si je rajoute maintenant le groupe adella dans ma liste des droits du répertoire public :

[root@villou serveur]# setfacl -m g:adella:rwx public

Vérifions :
[root@villou serveur]# getfacl public/
# file: public
# owner: root
# group: adm
user::rwx
group::rwx
group:adella:rwx
mask::rwx
other::r-x

Ce qui veut dire que l’utilisateur root, le groupe adm et le groupe adella peuvent créer des fichiers dans le répertoire public :

[utilisateur1@villou public]$ cat >> test
pour essais (CTRL+D)
[utilisateur1@villou public]$ ll
-rw-r--r-- 1 utilisateur1 adm 12 mar 1 21:11 test

Vérification de la gestion des ACLs avec SAMBA

Connectez-vous au domaine à partir d’un poste client NT2000 ou XP puis sélectionnez un répertoire ou un fichier auquel vous voulez gérer les accès : Propriétés/Sécurité.

Maintenant, à partir de la liste des groupes/utilisateurs affichés, vous pouvez ajouter des utilisateurs/groupes du domaine et attribuer des droits à chacun d’eux.

Valider puis vérifier que les modifications ont bien étés réalisées. S’il y a plusieurs utilisateurs/groupes, c’est que les ACLs sont bien gérés au niveau :
 du noyau
 du système de fichiers
 de SAMBA

On peut remarquer, qu’il y a une transposition des droits NTFS (Modifier, Lecture, Execution, Suppression,...) vers des droits UNIX (Lecture, Ecriture, Parcourir/Execution)

Vous pouvez maintenant adapter cet exemple à vos besoins. La gestion des ACLs n’est pas forcément intéressante pour tout le monde, les droits classiques des fichiers et répertoires suffisent dans la plupart des cas.

Articles connexes :
 Serveur de fichiers en Groupe de Travail (Workgroup)
 Samba en Contrôleur de Domaine

 Howto samba_ext3_acl

17/04/2005