Gestion des utilisateurs, groupes, permissions

Publié le 2006-09-142020-12-21 par sequanux

Gestion des utilisateurs, des groupes et des permissions dans un environnement Samba grâce aux ACLs.

Cet Article permet de mieux comprendre le fonctionnement des ACL dans un environnement hétérogène : serveur SAMBA avec ACLs et clients Windows, le tout dans un domaine (NT ou LDAP)

Samba sous Linux

Avant de comprendre comment sont appliqués les droits sur les fichiers il est important de décrire le fonctionnement de Samba sous Linux.

Samba est matérialisé, sur Linux, par un ’process’ qui tourne en tant que root. Il y a plusieurs process smb qui surveillent en permanence les ports SMB/CIFS et qui tournent en tant que root.
Linux est le système d’exploitation qui contrôle l’accès au système de fichiers.

Dès qu’un accès est autorisé par Samba ( identification et
authentification avec les informations contenues dans la base LDAP ), le process est dupliqué et tourne en tant que utilisateur Linux correspondant au compte Samba.

Quand Samba accède au système de fichiers, à travers Linux, c’est sousle compte Linux de l’utilisateur connecté. Linux contrôle ainsi les permissions accordées à l’utilisateur et à ses groupes sur les fichiers et les répertoires du partage.

Linux n’authentifie pas une nouvelle fois l’utilisateur ( d’ailleurs, il ne le fait jamais ), il fait confiance à Samba pour cela( qui s’exécute en tant que root avant de prendre l’identité de l’utilisateur ). Par contre il identifie l’utilisateur (uid, gid ) à partir des informations correspondantes stockées dans la partie POSIX des comptes LDAP. De même Linux contrôle l’appartenance aux groupes de l’utilisateur.
Pour contrôler les droits sur les partages et les répertoires, on distingue
3 niveaux :

contrôle par Samba de l’accès aux partage.
contrôle par Linux des permissions standards au système de fichiers.
contrôle par Linux des permissions étendues au système de fichiers(ACL)

Ces 3 niveaux s’appliquent en fonction des capacité du système de
fichier sous jacent. Pour un système de fichier ’ext2’ seules les 2 premiers niveaux sont applicables, pour les systèmes ’etx3’ ou ’xfs’, les 3 niveaux sont pris en compte sans modification du noyau Linux. ( Il faut néanmoins ajouter l’option ’acl’ pendant le montage des FS ’ext3’ )

Utilisateurs et Groupes

Approche de la gestion des utilisateurs et des groupes

Comment les utilisateurs sont ils vus ?

Les utilisateurs
Dans Windows, les utilisateurs sont identifiés par un nom d’utilisateur et un ’SID’.
Le ’SID’ est un élément composé du ’SID’ du domaine, suivi du ’RID’ de l’utilisateur, le RID étant un nombre identifiant l’utilisateur de manière unique dans le domaine :

SID Domaine	RID
S-1-5-21-1654345-14738625-73726-	1009

Certains RID ont une signification particulière , par exemple le RID 500 désigne l’Administrateur, le RID 501 désigne un compte Invité.

Dans la base Ldap, les attributs d’identification pour les entrées People sont :

uid : utilisateur (samba )
sambaSID : SID de l’utilisateur (samba )

Les groupes

Les groupes sont également identifiés par un nom de groupe et un SID. Certains RID de groupes ont une signification particulière dans le monde Windows, par exemple, le RID 512 correspond au groupe ’Administrateurs du domaine’, le RID 513 aux ’Utilisateurs du domaine’. Dans la base Ldap, les attributs d’identification des entrées Groupes sont :

DisplayName : nom du groupe Windows (samba )
sambaSID : SID du groupe (samba )

Correspondances utilisateurs – groupes

Chaque utilisateur appartient obligatoirement à un groupe, c’est le
groupe principal de l’utilisateur.
Dans la base Ldap, l’attribut sambaPrimaryGroupSID, désigne le groupe principal de l’utilisateur :

uid : utilisateur (samba )
sambaSID : SID de l’utilisateur (samba )
sambaPrimaryGroupSID : SID du groupe Window principal (samba )

De manière générale, un utilisateur aura comme groupe principal le groupe Windows ’Utilisateurs du domaine’, un administrateur le groupe principal ’Admins du domaine’

De plus, chaque utilisateur pourra appartenir à un ou plusieurs groupes secondaires, dans ce cas, l’utilisateur apparaîtra dans les attributs memberUid de chaque Groupe.

DisplayName : nom du groupe Windows (samba )
sambaSID : SID du groupe (samba )
memberUid : uid utilisateur 1 (samba )
memberUid : uid utilisateur 2 (samba )

Dans le monde Linux

Les utilisateurs

Comme pour Windows, les utilisateurs sont identifiés par un nom ( uid ) et par un numéro unique (uidNumber ).
L’uidNumber 0 correspondant à l’administrateur ( root ).
Dans la base Ldap, les attributs d’identification pour les entrée People sont :

uid : utilisateur (posix /samba )
uidNumber : numéro de l’utilisateur (posix )
sambaSID : SID de l’utilisateur (samba )
sambaPrimaryGroupSID : SID du groupe Window principal (samba )

On remarquera au passage que l’attribut uid ( utilisateur ) est
commun avec la classe d’objet Samba.

Les groupes

De la même manière, les groupes sont identifiés par un nom ( gid ) et par un numéro unique (gidNumber ). Sous Linux, il n’y a pas de groupe ayant des privilèges particuliers.
Dans le Ldap, on retrouvera les attributs suivants dans la branche
Groupes :

cn : nom du groupe (posix)
gidNumber : numéro du groupe (posix)
DisplayName : nom du groupe Windows (samba )
sambaSID : SID du groupe (samba )

Ici, on remarquera qu’il n’y a pas d’attributs commun avec les
groupes Windows.

Correspondances Utilisateurs – Groupes

Comme pour Windows, chaque utilisateur appartient à un groupe Linux principal.
Dans l’entrée Ldap People, ce groupe est indiqué par l’attribut gidNumber :

uid : utilisateur (posix / samba)
uidNumber : numéro de l’utilisateur (posix )
gidNumber : numéro du groupe principal Linux. (posix)
sambaSID : SID de l’utilisateur (samba )
sambaPrimaryGroupSID : SID du groupe Window principal (samba )

Il apparaît qu’il n’y a pas de correspondance directe entre le groupe Linux et le groupe Windows et que rien n’empêche d’avoir des groupes principaux Linux et WIndows qui n’ont pas de rapport entre eux. C’est pourquoi il est indispensable d’utiliser un outil de mise à jour de la base Ldap adapté.

Les utilisateurs peuvent également appartenir à un ou plusieurs groupes secondaires. Cette information est stockée dans l’attribut memberUid des Groupes :

cn : nom du groupe Linux(posix)
gidNumber : numéro du groupe (posix)
DisplayName : nom du groupe Windows (samba )
sambaSID : SID du groupe (samba )
memberUid : uid utilisateur 1 (posix /samba )
membreUid : uid utilisateur 2 (posix / samba )

On remarquera ici, que c’est le même attribut qui est utilisé pour les membres de groupes Windows et qu’il porte sur le même attribut commun : l’uid.

De Windows à Linux

Rôle de samba dans l’identification et le mapping de groupe

Passerelle de Windows vers Linux

Comme nous l’avons vu, une fois authentifié, samba accède au système de fichier en tant qu’utilisateur Linux correspondant à l’utilisateur Windows.
Son rôle est ici de ’mapper’ le SID de l’utilisateur vers son uid qui est commun avec Linux.
Quand un utilisateur s’authentifie, Samba lui renvoi son SID du domaine et c’est ce SID qui sera utilisé pour toute la session, Samba s’exécutant alors sur l’uid correspondant à l’utilisateur Linux. Linux retrouvera alors l’uidNumber correspondant à l’uid en interrogeant la base Ldap par nss_ldap.

Windows	<—>	Linux
sambaSID	uid	–
–	uid	uidNumber

Cependant, les permissions sont généralement appliquées pour des groupes et non pour des utilisateurs et Samba ne présente en aucune manière les groupes Windows à Linux. Il n’existe pas de groupes Samba, mais seulement des groupes Windows et des
groupes Linux.

Mapping de groupes

Quand Samba accède au système de fichier en tant qu’utilisateur, Linux effectue les requêtes d’identification sur la base Ldap par l’intermédiaire du module nsswitch_ldap afin de connaître l’uidNumber et les groupes d’appartenance de l’utilisateur.
Le module nsswitch retournera les groupes Linux auquels appartient l’utilisateur et c’est sur ces groupes que seront controlés les permissions.

Le module nsswitch_ldap n’a aucune conscience de l’existence de la classe Samba dans le Ldap.

Par exemple, prenons un utilisateur , qui est dans le groupe

<Utilisa.>

, SID : xxxxxxxxxx-513.

L’entrée de ce groupe, dans la branche Groupe se présente comme ceci :

cn : sambausers (posix)
gidNumber : 513 (posix)
DisplayName : Utilisa. du domaine (samba )
sambaSID : xxxxxxxx-513 (samba )
memberUid : toto (posix /samba )
membreUid : xxxx

Le module nsswitch retournera seulement les informations Posix, c’est à dire, pour l’utilisateur toto, qu’il appartient au groupe ’sambausers’ de gidNumber 513.

Le gidNumber 513 n’a aucun rapport avec le RID 513 du groupe
Windows ( c’est l’assistant de migration qui l’a créé comme cela ), ainsi que le nom du groupe ’sambausers’ qui ne correspond pas au nom du groupe Windows.

En fonctionnement, samba n’intervient pas dans le mapping de groupe. C’est du pur Ldap. C’est à la création des groupes où il faut faire très attention à la correspondance des noms de groupes Linux et Windows. C’est pourquoi il est fortement recommandé de créer les groupes à partir d’un outil d’administration qui permet de lever toute ambiguité (USRMGR par exemple, permet de créer les groupes Linux en même temps que les groupes Windows, et avec le même nom ).

Après une migration, ou une création de PDC avec l’assistant, seul le groupe Windows ’Utilisateurs du domaine’ à cette particularité. Ce n’est donc pas la peine de chercher ce groupe sur Linux qui héberge le PDC, il n’existe pas, c’est le groupe ’sambausers’.
Une autre erreur fréquente est , quand on utilise un client Ldap pour modifier la base des utilisateurs , de ne pas mettre le même groupe principal Linux que le groupe principal Windows ( si en plus ils n’ont pas le même nom, c’est vite la galère ) ou d’oublier d’ajouter l’utilisateur dans le groupe déclaré comme groupe principal.

Conseils

Si vous rencontrez des problèmes bloquant sur l’application des
permissions commencez par vérifier vos utilisateurs et leurs groupes d’appartenance :

les utilisateurs doivent être dans le groupe « Utilisa. du domaine »
les utilisateurs doivent avoir comme groupe principal « Utilisa. du domaine »
les administrateurs doivent être dans le groupe « Admins du domaine »
les administrateurs doivent avoir comme groupe principal « Admins du domaine »
vérifiez la concordance des groupes principaux Linux et Windows pour chaque utilisateur (gidNumber et sambaPrimaryGroupSID )

USRMGR est conseillé pour créer les utilisateurs et les groupes car les informations enregistrées dans le Ldap restent cohérentes.

On ne peut fixer, avec USRMGR, un groupe principal que si l’utilisateur est déjà dans ce groupe. Il existe des problèmes de rafraîchissement de USRMGR parfois déroutant ( mais qui s’expliquent très bien ), quand on fixe un groupe principal, il faut cliquer sur OK 2 fois ( la première fois on a un ’Accès refusé’ )

Les permissions Linux

Les droits sur les fichiers et répertoires sous Linux

Si vous avez bien lu les pages précédentes, vous savez que :

un utilisateur Windows correspond à un utilisateur Linux.
un groupe Windows ne correspond pas forcement à un groupe Linux,mais qu’il faut faire en sorte que cela soit le cas.
les groupes privilégiés de Windows, ou plus précisément les groupes Linux qui correspondent, n’ont pas de droits particuliers sur le système de fichiers.

Pour compléter l’exemple de la page précédente, le groupe « Admins du domaine » Windows qui a un RID 512, correspondra au groupe Linux du même nom mais avec un gidNumber totalement commun ( peut être 1590, si l’assistant de migration a été utilisé ). Le groupe « Admins du domaine » n’a aucun droits particulier sur Linux, par contre, un utilisateur appartenant à ce groupe, aura tous les privilèges sur une station Windows du domaine ( car le RID 512 sera reconnu par la station qui inclura l’utilisateur dans le groupe local des Administrateurs ).

Il existe cependant un paramètre de Samba ( smb.conf ) qui permet d’inclure tous les membres d’un groupe comme Administrateur :

admin users = « @Admins du domaine »

Dans ce cas, les membres du groupe Admins du domaine seront mappé en tant que root sur Linux. Ce qui revient un peu au même que le comportement que celui d’une station Windows, sauf que toutes les opérations seront faites en tant que root, et non en tant qu’utilisateur. Par exemple, si vous créez un fichier, celui ci aura comme proriétaire root, et non votre login d’utilisateur.

Les propriétaires et les permissions

Les propriétaires

Une permission est un droit accordé à une entité. Ce droit peut être de lire (r), d’écrire (w) ou d’éxécuter(x) pour un fichier, parcourir pour un répertoire.

Une entité est soit le propriétaire du fichier/repertoire ( owner ), le
groupe propriétaire du fichier/repertoire (group ) ou tous les autres (other ).

Sous Linux , quand on donne une permission, on ne la donne pas à un utilisateur ou à un groupe déterminé, mais on la donne au propriétaire et/ou au groupe propriétaire, et/ou aux autres.

Quand plus tard, nous parlerons de la propagation des droits, il s’agira de la propagation des permissions, pas des entités.

Pour modifier le propriétaire, ou le groupe propriétaire d’un
fichier/répertoire, il faut être soit même propriétaire du fichier, ou root. La commande a utiliser est :

chown [-R] [ :] repertoire>

Par exemple, pour modifier le propriétaire par root :

chown root repertoire>

Pour modifier le propriétaire et le groupe :

chown root : »Admins du domaine » repertoire>

Pour modifier en récursif

chown -R root : »Admins du domaine »

Les permissions

Pour attribuer des permissions aux entités propriétaires, il faut utiliser la commande chmod.

Il existe plusieurs syntaxes de la commande chmod. La plus ’parlante’ étant celle ci :

chmod [-R] <+|-|=>[permissions] [,] … repertoire>

Pour donner les droits de lecture (read) , d’ écriture (write ), de
parcours ( execute ), pour un répertoire :

chmod u=rwx,g=rx,o=

Dans ce cas, le propriétaire pourra lire, écrire et parcourir, le groupe propriétaire pourra lire et parcourir, les autres ne pouront rien faire.

Souvent, on veut également donner les mêmes permissions aux sous répertoires, on utilisera donc la commande en récursif avec l’option -R

Pour les fichiers, le x, signifie éxécution. Cela n’a de sens que si le
fichier est accédé à partir de Linux. Sous Windows, le bit x n’a pas de signification d’éxécution, par contre il peut être utilisé par Samba pour mapper des informations propres à Windows ( bit d’archivage entre autre)

Initialisation et propagation des permissions
Linux

Le positionnement des permissions à la création d’un fichier et leur propagation

Création d’un nouveau fichier ou répertoire
Sous Linux, quand un nouveau fichier, ou répertoire est créé, celui ci hérite comme propriétaire et groupe propriétaire, de l’identité et du groupe principal de l’utilisateur qui l’a créé.

Par exemple, si toto, dont le groupe principal est sambausers, créé un fichier les entités de ce fichier seront :

propriétaire : toto

groupe propriétaire : sambausers

Les permissions sont fixées par rapport à un masque , qui est défini pour chaque utilisateur : la variable UMASK. Cette valeur est définie dans les variables d’environnement Linux de l’utilisateur, en général elle est de 022.

Pour connaitre les permissions attribuées au nouveau répertoire, il suffit d’inverser (en binaire ), la valeur du umask :

umask 022 -> pour un répertoire -> 755 = rwx r-x r-x

Si il s’agit d’un fichier, le bit x ( éxécution ) n’est pas positionné

umask 022 -> pour un fichier -> 644 = rw- r— r—

Dans ces conditions, si toto créé un nouveau répertoire, celui ci aurra comme permissions :

drwxr-xr-x toto sambausers repertoire_de_toto

Ce qu’il faut comprendre, c’est qu’à priori, les propriétaires et les
permissions des nouveaux fichiers et répertoires ne dépendent pas du répertoire dans lequel il sont créés mais de l’utilisateur qui les créé.

Quand un utilisateur modifie un fichier dont il n’est pas propriétaire, mais dont un des groupes auquel appartient l’utilisateur à le droit d’écriture, le propriétaire n’est pas modifié. Mais il faut tenir compte de l’application qui est utilisée pour modifier ce fichier. Par exemple, Word 2000, créé une nouvelle copie et efface l’ancienne, ce qui à l’effet d’une création , donc de la modification du propriétaire.

Propagation du groupe propriétaire

Dans les conditions décrites précédement, on s’apperçoit qu’il est
difficile de maintenir une cohérence dans les permissions sur les fichiers et les répertoires.

Supposons que nous déclarions un répertoire dont les permissions
seraient :

drwxrwx— root groupeSecretaires repertoireSecretaires

Un utilisateur, membre de ’groupeSecretaires’ pourrait créer de
nouveaux fichiers dans ce répertoire. Cependant, les permissions sur le nouveau fichier seraient positionnées comme ceci :

rw-r—r— toto sambausers fictoto

Pourquoi ? parce que toto est bien membre du groupeSecretaires, mais son groupe principal est ’sambausers’. De plus, son UMASK est à 022, donc les permissions sont misent à rw-r—r—
Il existe un moyen de propager le groupe propriétaire d’un répertoire à tout nouveau fichiers, le SGID bit. Son positionnement se fait par la commande

chmod g+s repertoireSecretaires

drwxrws— root groupeSecretaires repertoireSecretaires

Si un membre autorisé créé un nouveau fichier, nous aurons
’groupeSecretaires’ comme groupe propriétaire, quelque soit le groupe
principal de l’utilisateur :

rw-r—r— toto groupeSecretaires fictoto

Si il s’agit d’un nouveau répertoire

drwxr-sr— toto groupeSecretaires reptoto

Vous remarquerez que seul le groupe propriétaire est propagé, pas les permissions qui sont toujours défine par le UMASK de l’utilisateur. On peut également positionner le SGID bit à la création des permissions :

chmod g=rwxs

Attention, le ’s’ masque , à l’affichage le ’x’ de droit de parcours. Si le ’s’ est minuscule, il inclus le ’x’. Si le ’S’ est majuscule, il exclu le ’x’.

chmod g=rwxs —-> rws = rwx + s

chmod g=rws —-> rwS = rw- + s

Propagation des permissions par Samba

Les capacités de Linux, en terme de propagation se limitent à cela. Ce qui n’est toujours pas satisfaisant, les membres du groupeSecretataires ne peuvent pas écrire dans les nouveaux répertoires. Cependant, quand le fichier, ou le répertoire, sont créés à partir de Samba, un paramètre dans le fichier smb.conf permet la propagation des permissions du répertoire parent :

inherit permissions = yes

Dans ce cas, et si seulement le fichier est créé via Samba, les
permissions Linux du répertoire parent seront propagées aux nouveaux fichiers et répertoires, le groupe propriétaire sera propagé par Linux avec le SIGID bit, le propriétaire sera l’utilisateur qui créé le fichier / répertoire :

rw-rw— toto groupeSecretaires fictoto

drwxrws— toto groupeSecretaires reptoto

Nous retrouvons les même permissions ( au propriétaire près et au ’x’ près pour les fichiers ) que celles du répertoire parent.
Dans le cas où la directive inherit owner = yes, le propriétaire sera
également hérité du répertoire parent. On perdra donc l’information de ’propriété’ du fichier, mais cela peut être un choix.

Les permissions étendues ( ACL )

Définition et fonctionnement des ACL étendues
Comme nous l’avons vu précedement

Linux limite l’attribution des permissions à 3 entités : le propriétaire, le groupe propriétaire et les autres.
Les permissions appliquées à ces entités dépendent de l’utilisateur qui créé les fichiers, par son UMASK.
Le groupe propriétaire peut être propagé aux nouveaux fichiers et
répertoires par le SGID bit
Enfin, Samba permet de propager les permissions ( éventuellement le propriétaire ) du répertoire parent aux nouveaux fichiers et répertoires.

Comme nous le verrons plus loin, ces permissions ’standards’ sont très difficilement gérables par l’explorateur de fichiers sous Windows. De plus, le nombre de groupes à administrer étant parfois très importants, il n’est pas concevable de se limiter aux permissions ’standards’.

Cependant, et comme il faut bien définir des permissions aux fichiers et répertoires que l’on voudra partager, il est recommandé de s’en tenir aux entités standardisés du systèmes , à savoir root et le groupe « Admins du domaine ».

Ainsi, pour créer un nouveau répertoire, destiné à être partagé, les
permissions à appliquer seront :

drwxrws— root Admins du domaine repApartager

Cela s’obtient par les commandes :

mkdir repApartager

chown root : »Admins du domaine » repApartager

chmod u=rwx,g=rwxs,o= repApartager

note : n’oublier pas le SGID bit ( g=rwxs ), qui permettra la propagation du groupe propriétaire « Admins du domaine » à tous les fichiers et répertoires. ( consulter la page ’rustineXFS’ pour les FS XFS )

Nous pouvons qualifier ces permissions comme des permissions
« administratives » qui garantissent l’accès aux fichiers par les
administrateurs du domaine.

Les ACL

Les ACL ( Access Control List ) ou Liste de controle d’accès, comme leur nom l’indique, permettent de définir des permissions à une liste d’utilisateurs et/ou de groupes supplémentaires.
La grande différence avec les permissions Linux, est que celles ci sont appliquées , non pas à des entités non définies, mais à des entités nommées.
Par exemple on pourra définir des permissions à un groupe nommé, pas seulement au groupe propriétaire.

Les ACLs standards

Les ACL standards ( ou minimale ) sont tout simplement les permissions Posix accordées au propriétaire, ou groupe propriétaire du répertoire et aux autres.

la commande getfacl permet de lire les acls :

getfacl repApartager

# file : repApartager

# owner : root

# group : Admins�40du�40domaine

user ::rwx

group ::rwx

other ::—

Les informations user ::, group :: et other :: correspondent aux
permissions Posix.
La modifications des permissions Posix par chmod, modifie également la
valeur des ACL standard, quand il n’y a pas d’autres ACL
ACL standard = permissions Posix ( si pas d’autres d’ACL ) = ACL
minimales

Les ACLs d’accès

Les ACLs d’accès ( ou étendues ) sont toutes les permissions
supplémentaires accordées aux utilisateurs et groupes autres que le propriétaire et le groupe propriétaire.

Il n’est pas recommandé de placer des ACL pour des utilisateurs, car cela deviendrait rapidement ingérable. Efforcer vous de donner des ACL aux groupes. Créer un groupe pour un seul utilisateur n’est pas choquant en soit, cela permet de bien séparer les individus de leur fonction. Par exemple , le groupe DIRECTEUR, ne peut contenir que le directeur. A sa mutation, il suffit de changer le membre du groupe DIRECTEUR sans toucher aux droits sur les fichiers.

Pour placer des ACL, pour un groupe, il faut utiliser la commande
setfacl -m g :

setfacl -m g:entite:permissions fichier>

Il existe d’autres arguments pour la commande setfacl, référez vous au
man.

Par exemple, les commandes :

setfacl -m g:DIRECTEUR:rwx repApartager

setfacl -m g:sambausers:r-x repApartager

accordent les droits d’écriture , de lecture et de parcours au groupe
DIRECTEUR et les droit de lecture seule et de parcours au groupe
sambausers.

Ces ACL sont représentées par la commande getfacl

# file : repAparatger

# owner : root

# group : Admins�40du�40domaine

user ::rwx

group ::rwx

group:sambausers:r-x

group:DIRECTEUR:rwx

mask ::rwx

other ::—

Pour supprimer une ACL, utiliser la commande setfacl -x g :
Pour supprimer toutes les ACL, utiliser la commande sefacl -b
Pour appliquer la commande setfacl en récursif sur tous les fichiers et sous-répertoires utiliser l’option -R

Il apparait, une nouvelle entrée d’ACL qui est le mask. Cette entrée
permet de masquer les permissions déclarées. Les permissions réellement appliquées ( permissions effectives ) sont celles issues du ET logique avec le masque.

Ce masque est calculé à partir des permissions données au groupe propriétaire, c’est pourquoi, il est impératif que les permissions du groupe propriétaire soit toujours rwx, pour éviter de masquer les ACL.

D’autre part, quand des ACL d’accès sont positionnées, les ACL
minimales ne seront pas modifiées par la commande chmod.

Initialisation et propagation des permissions
étendues (ACL)

Comment sont initialisées et propagées les ACL lors de la création de nouveaux fichiers ou répertoires En présence d’ACL d’accès, la création d’un nouveau fichier ou répertoire ne modifie en rien le comportement d’initialisation et de propagation des permissions. Tout nouveau fichier ou répertoire sera créé sans ACL. (exepté les ACL minimales, qui correspondent aux permissions Posix )

Pour que des ACL puissent être propagées, le répertoire parent devra posséder des ACL par défaut.

Les ACL par défaut

Les ACL par défaut sont des ACL qui seront propagées aux nouveaux fichiers et répertoires.

Ces nouveaux fichiers/répertoires auront , comme ACL d’accès, la valeur des ACL par défaut. Les ACL par défaut sont également propagées aux nouveaux répertoires permettant ainsi une nouvelle propagation en cascade.

Les ACL d’accès et les ACL par défaut sont des données totalement
indépendantes.

Sous Linux, pour qu’il ai propagation des ACL il faut que le répertoire parent possède des ACL par défaut.

A partir de Samba, la propagation des ACL d’accès est assurée, même si il n’y a pas d’ACL par défaut. Cependant , et dans ce cas, il n’est plus possible de gérer correctement les droits à partir du gestionnaire de fichier Windows.
Il est possible d’avoir des ACL d’accès, différentes des ACL par défaut , mais cela n’est pas recommandé pour un serveur de fichiers, car la gestion des droits, à travers Windows deviendrait rapidement incompréhensible. Nativement ce sont les ACL par défaut qui sont propagées, pas les ACL d’accès.

nouveau répertoire/fichier -> ACL d’accès : les ACL par défaut du
parent

nouveau répertoire -> + ACL par défaut : les ACL par
défaut du parent

Pour créer des ACL par défaut, pour un groupe, la commande est
setfacl -m d:g :

setfacl -m d[efault]:g : :

Pour revenir à l’exemple précedent :

setfacl -m d:g:DIRECTEUR:rwx repDirecteur

setfacl -m d:g:sambausers:r-x repDirecteur

Vous pouvez également utiliser la commande suivante pour recopier
toutes les ACL d’accès dans les ACL par défaut :

getfacl —access | setfacl -d -M-

La commande getfacl , pour ce répertoire donnera :

# file : repDirecteur

# owner : root

# group : Admins�40du�40domaine

user ::rwx

group ::rwx

group:sambausers:r-x

group:DIRECTEUR:rwx

mask ::rwx

other ::—

default:user ::rwx

default:group ::rwx

default:group:sambausers:r-x

default:group:DIRECTEUR:rwx

default:mask ::rwx

default:other ::—

On remarquera, que lorsque des ACL par défaut sont positionnées, des ACL par défaut pour les ACL standards ( Posix ) sont automatiquement positionnées, reprenant les permissions Linux pour le propriétaire et le groupe propriétaire.
Donc la création d’un nouveau fichier dans ce répertoire, sous Linux , donnera :

rw-rw—- toto Admins du domaine ficdetoto

Remarquez que les permissions pour le groupe propriétaire est rw- et pour other —, ceci ne correspond plus au UMASK de l’utilisateur, c’est la propagation des ACL standards.
La directive inherit permissions = yes n’est donc théoriquement plus nécessaire sur Samba.

La commande getfacl sur ce fichier donne :

# file : ficdetoto

# owner : toto

# group : Admins�40du�40domaine

user ::rwgroup ::

rwx #effective:rwgroup :

sambausers:r-x #effective:r—

group:DIRECTEUR:rwx #effective:rwmask ::

rwother ::—

On remarquera qu’il y a application d’un masque ( rw-, qui est la valeur des permissions pour le groupe propriétaire ) . Ceci permet de masquer le bit x ( exécution ), puisque que c’est un fichier. Il ’y a pas non plus d’ACL par défaut, c’est également normal, il s’agit d’un fichier.

Création d’un répertoire :

drwxrwx— toto Admins du domaine reptoto

L’ACL par défaut pour les ACL standards est bien propagée (rwx pour le
groupe, — pour other ).

# file : dirtoto

# owner : toto

# group : Admins�40du�40domaine

user ::rwx

group ::rwx

group:sambausers:r-x

group:DIRECTEUR:rwx

mask ::rwx

other ::—

default:user ::rwx

default:group ::rwx

default:group:sambausers:r-x

default:group:DIRECTEUR:rwx

default:mask ::rwx

default:other ::—

Les ACL d’accès et les ACL par défaut sont également bien propagées.

Tout semble parfait, cependant …. si nous créons un nouveau répertoire dans ce dossier :

su toto

cd dirtoto

mkdir newdir

drwxrwx— toto sambausers newdir/

Le nouveau sous répertoire , à comme groupe propriétaire, sambausers, et non pas Admins du domaine . Pourquoi ?

Le SGID bit n’a pas été propagé.
Quand des ACL par défaut sont positionnées, il faut que le créateur
fasse partie du groupe propriétaire pour que SGID bit soit propagé sur un système de fichier XFS. C’est un bug signalé de XFS. ( voir la page rustineXFS )

A partir de Samba, les ACL d’accès seront propagées, même si il
n’existe pas d’ACL par défaut. Cependant, le gestionnaire de fichier
Windows n’affichera pas les permissions si les ACL par défaut ne sont pas positionnées ce qui rendra la gestion des droits, par WIndows, très hasardeuse.

Manipulation des ACL à partir de Windows

Comment manipuler les ACL à partir du gestionnaire de fichier Windows (onglet sécurité)

Les permissions Linux

Les permissions Linux, propriétaire, groupe propriétaire et autre, ne sont pas cochées dans le gestionnaire Windows, quand il s’agit d’un répertoire. Par contre, les entités correspondantes sont bien identifiées.

Il ne faut pas tenter de modifier les permissions Posix par l’intermédiaire du gestionnaire Windows. C’est pourquoi, on gardera comme groupe propriétaire le groupe « Admins du domaine », ce qui permettra de repérer qu’il s’agit bien d’une entrée Posix.
Il est impératif de définir un groupe propriétaire qui le sera le même pour tous les fichiers et répertoires ( « Admins du domaine » ) et clairement identifié. Ne jamais modifier les permissions à partir de Windows pour ce groupe.

Les ACL standards – minimales

Les ACL minimales, sont également représentées dans le gestionnaire de fichiers Windows, il s’agit des entrées CREATEUR PROPRIETAIRE et GROUPE PROPRIETAIRE et Tout le monde. Comme pour les entrées Posix, les permissions ne sont pas cochées.

Il ne faut pas modifier ces entrées par le gestionnaire.

Positionnement des permissions

Le gestionnaire Windows permet d’ajouter des permissions pour un
groupe du domaine, par le bouton ’Ajouter’.
Les droits pris en compte sont alors :

LIRE-ECRIRE-PARCOURIR : controle total + tous les autres droits : rwx
LIRE-PARCOURIR : lecture exécution + afficher le contenu + lecture : r-x

Samba créé automatiquement les ACL par défaut correspondantes. Ce qui permet d’afficher et de modifier les permissions.

Les permissions ne s’affichent pas

Quand les permissions ne s’affichent pas dans le gestionnaire Windows, et qu’il s’agit d’un groupe autre que le groupe posix, cela signifie que les ACL par défaut ne sont pas positionnées ou alors qu’il y a une différence entre les ACL par défaut et les ACL d’accès du répertoire courant.

Il faut impérativement corriger ces problèmes en affectant les bons
droits à partir du gestionnaire Windows, ce qui aurra pour effet de
postionner les ACL d’accès et les ACL par défaut aux mêmes valeurs.

Héritage des permissions à partir de Windows

Les ACL par défaut sont reconnues comme telles par Windows
Quand des ACL par défaut sont positionnées, celles ci sont propagées, à la création des nouveaux sous répertoires. Les mécanismes d’héritage de Windows sont correctement pris en compte.

Permissions héritées

A partir du gestionnaire de fichier Windows, les permissions héritées du répertoire parent sont grisées. Vous ne pouvez donc pas les modifier sans casser l’héritage, tout comme sous Windows.

A ce niveau, si on ajoute de nouvelles permissions, par Windows, celles-ci ne seront pas grisées ( car ce ne seront pas des permissions héritées ), par contre elles le seront pour les nouveaux sous-répertoires.

Modification de l’héritage

Tout comme sous Window, il est possible de casser l’héritage pour un sous répertoire. Cela se fait en décochant la case : Permettre aux autorisations pouvant être héritées …

Il y a alors 2 possibilités :

1) copier les permissions héritées.

2) supprimer les permissions héritées.

Copier les permissions héritées

Celles ci seront alors considérées comme des permissions ’non héritées’ et leur modification sera possible.
Samba mémorise l’information d’héritage dans un attribut du système de fichier ( EXT3 et XFS possèdent une quinzaine d’attributs supplémentaires, en plus des droits et des ACL ).

Supression des permissions héritées

La supression supprime toutes les permissions héritées du répertoire parent. Seules les ACL qui ne correspondent pas à celles du répertoire parent sont conservées.
Cependant, pendant cette opération les ACL minimales sont modifiées, notamment celle du groupe propriétaire qui est mise à 0 ( — ), mais le masque n’est pas modifié ( il reste à rwx ).

Ce comportement n’introduit pas de modification de l’application des permissions, mais il peut entraîner une certaine incompréhension quand on lit les ACL par Linux. C’est pourquoi, il est recommandé de ne pas supprimer les permissions héritées.

Au besoin, il est préférable de les copier, puis de les supprimer.

Rétablir l’héritage

Pour rétablir l’héritage, il faut de nouveau cocher la case ’Permettre aux autorisations …’, les ACL d’accès et les ACL par défaut du répertoire parent seront alors recopiées.

Attention cependant, si il existe déjà une ACL pour un groupe mais que les permissions sont différentes que celles du répertoire parent, celle ci ne sera pas modifiée.

Recommandations

En règle générale, il n’est pas conseillé de casser l’héritage dans les
partages, car cela donne une très mauvaise image de l’organisation des
droits surtout dans le cas ou l’on doit réaffecter les permissions en récursif
sur un répertoire racine.

Les droits par la pratique

Conseils et recommandations.

Cette page reprend les constations développées dans les pages précédentes.

Merci de vous y référer pour une meilleure compréhension.
Les utilisateurs et les groupes Utiliser un client SMB/CIFS ( USRMGR ) pour créer/modifier vos utilisateurs et vos groupes globaux.

Si ce n’est pas le cas, et si la base de données des utilisateurs à été initialisées avec un client Ldap ( PhpLdapAdmin, Lam … ), vérifier que les groupes principaux Windows (SambaPrimaryGroupSID ) et les groupes principaux Linux correspondent entre eux ( gidNumber )

Vérifier que tous vos utilisateurs appartiennent au groupe « Utilsa. du domaine » RID 513 ( gid sambausers ) et que ce groupe soit leur groupe principal (fixer le groupe principal).

Vérifier que les utilisateurs ayant fonction d’administrateur
appartiennent en plus, au groupe « Admins du domaine » RID 512 et que ce groupe soit leur groupe principal (fixer le groupe principal ).

Le système de fichiers

Efforcer vous de réserver une partition pour les répertoires partagés. (/smb par exemple ).

Cette partition sera formatée en XFS ou EXT3. Dans le cas d’une
partition EXT3, celle ci devra être montée avec l’option acl.

les performances sont nettement moins bonnes en EXT3.
XFS contient un bug référencé concernant la propagation du groupe propriétaire des répertoires avec les ACL.

Une ’rustine’ est proposée dans la page ’rustine XFS’ pour corriger ce problème en attendant une mise à jour éventuelle du noyau Linux.

La sécurisation Mandriva

Mandriva propose en standard un système de sécurisation (DrakSec) qui a la particularité de rétablir périodiquement (toutes les heures) les permissions sur les fichiers et répertoires à une valeur définie par l’administrateur (msec).

Vérifier, que les directives de sécurisation ne modifient pas les
permissions de vos répertoires partagés ( utiliser DrakPerm en mode graphique, ou le fichier /etc/security/msec/perm.local ). Une raison de plus pour que vos partages soient dans une partition bien séparée du reste des fichiers Linux.

La création des partages

Les répertoires partagés sont créés sous Linux – il n’existe pas d’autre moyen.

Autant que possible, les répertoires partagés seront créés directement à la racine de la partition réservée pour cela (/smb par exemple).

Il faut éviter d’avoir des répertoires partagés inclus dans des partages existant car cela ne facilite pas l’administration des permissions.

Il faut réfléchir à la stratégie des permissions avant de définir les
partages : qui peut lire ?, qui peut écrire ?.

Créer le répertoire partagé avec le compte ’root’ :

mkdir

Fixer le propriétaire et le groupe propriétaire du répertoire :

chown root : »Admins du domaine »

Fixer les permissions dites ’administratives’ et le bit de propagation du groupe propriétaire :

chmod u=rwx,g=rwxs,o=

attention : le sgid bit est ici fixé, par le s de groupe : g=rwxs , ne pas l’oublier

Définir les ACL du partage en lecture

A ce niveau, il faut définir le groupe qui sera autorisé à lire dans le
partage. Si tous les utilisateurs du domaine peuvent lire , ce sera le groupe ’sambausers’ ( pour un PDC ), ou le groupe « Utilisa. du domaine » (pour un serveur Membre).

Si le contenu du partage ne doit pas être lu par tout le monde (les
utilisateurs du domaine), il faut indiquer le(s) groupe(s) autorisé(s) à lire.

A ce sujet, samba ne gère pas les groupes locaux, c’est à dire les ’groupes de groupes’, il faut donc soit

créer un groupe qui contienne les membres des ’sous-groupes’
soit affecter une ACL pour chaque groupe (dans ce cas il faudra casser l’héritage pour permettre l’écriture)

setfacl -m g:sambausers:r-x

setfacl -m g :<groupe1>:r-x

setfacl -m g :<groupe2>:r-x
….

ensuite, il faut initialiser les ACL par défaut qui seront propagées aux nouveaux sous-répertoires du partage. On utilisera toujours la copie des ACL d’accès.

getfacl —access | setfacl -d -M-

Il n’est pas conseillé de donner des droits d’écriture sur le répertoire à partager. Afin de mieux maitriser l’organisation des répertoires sur le serveur, ce droit n’est donné que par les permissions posix au groupe « Admins du domaine ».

Les droits d’écriture seront ensuite donnés sur les sous-répertoires par l’administrateur, directement sous Windows.

Cela permet également d’éviter que les utilisateurs n’enregistrent des fichiers directement au premier niveau du partage et les oblige ainsi à les classer dans les sous-répertoires.

Pour les partages qui doivent contenir beaucoup de répertoires, vous pouvez donner les droits d’écriture à un groupe restreint de personnes (PRI de service par exemple ), pour leur permettre de créer des nouveaux répertoires dans le partage.

Attention : les commandes décrites ci dessus sont à appliquer pour la création de nouveaux partages. Si le partage existe déjà et qu’il contient déjà des fichiers il faut appliquer les commandes en récursif avec l’option -R pour que les modifications soient appliquées aux répertoires et fichiers existants.

Auparavant, utiliser la commande setfcal -R -b pour supprimer toutes les ACL existantes.

Pour fixer les ACL par défaut, utiliser alors la commande setfacl -R -m d:g pour chaque groupe, car la commande globale de recopie des ACL d’accès dans les ACL par défaut ne fonctionne pas en récursif.

La définition du partage dans Samba

Pour définir le partage dans Samba, utilisez WebMin, SWAT ou éditer le fichier /etc/samba/smb.conf

[NOMDUPARTAGE]

path=/smb/nouveau_partage

writable = yes

valid users = « @sambausers »

Cela suffit, il n’est pas nécessaire d’indiquer de directives d’acces
supplémentaires car elles feraient double emploi avec les ACL et
introduiraient un niveau de sécurité supplémentaire qui pourrait être incompatible avec les ACL.

On peut rajouter la directive

public = yes

si on veut que le partage soit accessible par un compte Invité. ( voir la doc sur la configuration de samba )

Les options suivantes devront être vérifiées dans la section globale du fichier smb.conf :

inherit acls = yes ; permet la propagation normale des acl par défaut, sans être masqué par un éventuel mode de permission.
map acl inherit = yes ; permet de mémoriser dans les attributs étendus du système de fichiers les informations telles que ’héritage’ ou ’lecture seule’ qui sont des attributs propres à Windows non pris en compte par les ACL.
nt acl support = yes ; indique de prendre en compte les ACL comme des permissions Windows. L’onglet ’sécurité’ du gestionnaire de fichiers Windows est alors activé.
inherit permissions = no ; permet la propagation des permissions posix aux nouveaux répertoires et fichiers. Cette directive n’est pas nécessaire, puisque que ce sont les ACL minimales par défaut qui agissent. Mettre ’no’ permet la prise en compte des directives create mask, directory mask … pour les partages homes et Profiles.

Recharger le fichier smb.conf :

service smb reload

La création des sous-répertoires

Cela se fait en accedant au partage sous Windows, sous un compte « Admins du domaine ». A ce niveau seuls les « Admins du domaine », peuvent créer des répertoires.

A la création, les ACL par défaut seront héritées du répertoire parent. Donner les droits d’écriture, par l’onglet sécurité, dans les nouveaux sous-répertoires (Controle total) aux groupes supplémentaires (qui doivent avoir pour membres les utilisateurs du groupe fixés en lecture sur le répertoire du partage).

Vous pouvez également casser l’héritage, en donnant un droit d’écriture aux groupes du répertoire parent qui n’en ont pas. Dans ce cas, copier les permissions héritées et modifier les. Il faut éviter de casser l’héritage trop profondément dans la hiérachie pour garder une bonne visibilité. Ne jamais modifier ou supprimer les permissions des groupes posix « Admins du domaine », GROUPE PROPRIETAIRE, Tout le monde, de l’utilisateur propriétaire et CREATEUR PROPRIETAIRE. Ces permissions ne sont pas cochées pour les répertoires.

Si des permissions ne sont pas visibles ( aucune case cochée ), il s’agit d’un des groupes precedement cité ou du créateur propriétaire, il ne faut pas les modifier. Si il s’agit d’un autre groupe du domaine, c’est qu’il y a une incohérence entre les ACL d’accès et les ACL par défaut, corriger le problème en réaffectant les bons droits en récursif, tout devrait rentrer dans l’ordre.

Si des permissions apparaissent en grisé, elles ne sont pas modifiables, il s’agit de permissions héritées du répertoire parent. Dans ce cas on peut casser l’héritage en décochant la case ’Permettre aux autorisations pouvant être héritées du parent d’être propagées à cet objet’. Il faut alors copier les permissions, plutôt que les supprimer. On pourra ensuite les modifier ou les supprimer individuellement.

Pour rétablir l’héritage, cocher la case ’Permettre aux autorisations …’. Les ACL du parents seront alors recopiées sauf celles qui diffèrent.

Ne donner pas de permissions à des utilisateurs, donner les à des
groupes, même si il n’ont qu’un seul membre. Cela permet de séparer les fonctions des individus et de ne pas à avoir à modifier les permissions quand un utilisateur change de groupe.

Propriétaires des fichiers.

A la création, tout nouveau fichier et répertoire aura comme propriétaire l’utilisateur qui l’a créé. Si le fichier est modifié par un logiciel ( ce qui généralement le cas ), le propriétaire peut changer si le logiciel fait une nouvelle copie du fichier ( Word 2000 par exemple ).

Maintenant, c’est au choix :

soit vous préférez que chaque créateur reste propriétaire de ses fichiers ( ça permet de savoir qui a fait quoi, au cas où ), dans ce cas, si un utilisateur change de groupe, il restera propriétaire des ses fichiers et répertoires et pourra toujours les modifier.
soit , on applique une stratégie d’héritage de propriétaire. Tous les fichiers et répertoires auront le même propriétaire que le répertoire parent ( root ).

Pour cela il faut indiquer la directive

inherit owner =

yes dans le fichier smb.conf

Modification récursive des permissions.

Quand les répertoires existent déjà dans le partage, il faut appliquer toutes les opérations de droits en récursif.

Cela peut se faire par Windows, ( sauf sur le partage lui même ), par le bouton ’Avancé – case ’Réinitialiser les permissions sur tous les objets …’, mais cela est très long.

Préférez, dans ce cas, les commandes setfacl -R -m -g : et setfacl -R -m
d:g :, en ayant pris soin, si on veut repartir à zéro, de supprimer toutes les acl par setfacl -R -b.

rustine XFS

Une rustine qui permet de colmater une brèche de sécurité du système XFS.

Le système de fichier XFS ( eXtended Files System ) développé par
Silicon Graphic, est le système actuellement le plus performant en terme de journalisation, capacité à gérer les quotas, les acl et les attributs étendus.

Cependant, il existe un bug, qui ne permet pas de propager le SGID bit d’un répertoire quand des ACL par défaut sont positionnées et que l’utilsateur qui créé le répertoire ne fait pas partie du groupe propriétaire du répertoire parent.

Le SGID bit est utilisé dans la stratégie de permissions exposée dans ce guide, justement pour éviter de de fixer le groupe propriétaire des répertoires par celui du groupe principal de l’utilisateur et donner ainsi des droits d’écriture à tous les membres du groupe ( les droits rwx, sont propagés par l’ACL minimale par défaut ).

Pour ’corriger’ cela ( ou plutôt pour ’réparer’ ), on appliquera une
stratégie de sécurité équivalente à ’msec’. msec est développé en python, qui n’utilise pas la librairie de Linux, donc ne connait pas les groupes du Ldap. De plus, msec ne permet pas d’appliquer les modifications de permissions en récursif.

Nous utiliserons alors un très léger script, déclenché toutes les heures par cron afin de rétablir le groupe propriétaire et le SGID bit sur tous les répertoires partagés.

Il suffit de copier les lignes suivantes dans un fichier texte et de
l’enregistrer dans le répertoire /etc/cron.hourly sous le nom ( peut
importe ) ’rustinexfs’

# !/bin/sh

# correction du SGIDbit pour XFS quand ACL par defaut

chgrp -R « Admins du domaine » /smb/*

chmod -R g+s /smb/*

A condition que vos partages se trouvent tous et uniquement dans /smb ( sinon modifier ou recréer les 2 dernières lignes pour chaque répertoire partagé ).

Donner le droit d’exécution pour root :

chmod 750 rustinexfs

Ainsi, la ’faille’ de sécurité ne sera pas présente plus d’une heure. C’est un moindre mal.

NB : ce bug ne pourra être corrigé ( si il l’est un jour ) que par un
changement de version du noyau linux.

NB : ce script introduit également un sgid bit sur les fichiers. Ce n’est pas génant dans le cas où ce ne sont pas des fichiers exécutables par Linux ( de plus le groupe ’Admins du domaine’ n’a aucun droit sous Linux )

Un grand merci à mon ami Jean-Luc