Lea Linux - Contributions [fr]

Gestion des ACL

2006-09-24T17:58:22Z

Vincent Ramos : /* Interaction avec KDE */ Nouvelle section

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modifications : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ces paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commandes, il faut préciser explicitement que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Interaction avec KDE===
Le gestionnaire de bureau [http://www.kde.org KDE] permet, depuis la version 3.5, de visualiser et manipuler les ACL des fichiers. Il suffit de cliquer avec le bouton droit de la souris sur un fichier et de sélectionner l'onglet « Droits d'accès » puis « Droits d'accès avancés ». De là, on peut consulter l'ACL du fichier de manière graphique.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl --skip-base -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl --skip-base -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichiers ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.linuxfrench.net/article.php3?id_article=1463 Comment fonctionnent les ACL POSIX sous GNU/Linux] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux] (anglais).

{{Copy|27.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2006-06-14T11:13:26Z

Vincent Ramos : /* Noyau */ typo

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modifications : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ces paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commandes, il faut préciser explicitement que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl --skip-base -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl --skip-base -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichiers ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.linuxfrench.net/article.php3?id_article=1463 Comment fonctionnent les ACL POSIX sous GNU/Linux] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux] (anglais).

{{Copy|27.10.05|Vincent Ramos|FDL}}

Trucs:Oldid=575

2005-11-01T11:36:50Z

Vincent Ramos : #REDIRECT Trucs:Installation des drivers Nvidia 6xxx 10.1 Community 'kernel 2.6.8.1-xx-mdk)

#REDIRECT [[Trucs:Installation des drivers Nvidia 6xxx 10.1 Community 'kernel 2.6.8.1-xx-mdk)]]

Gestion des ACL

2005-10-28T18:18:22Z

Vincent Ramos : /* Documents annexes */ Intitulé du lien « Comment fonctionne les acls Posix sous linux » → « Comment fonctionnent les ACL POSIX sous GNU/Linux »

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichiers ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.linuxfrench.net/article.php3?id_article=1463 Comment fonctionnent les ACL POSIX sous GNU/Linux] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux] (anglais).

{{Copy|27.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T18:16:39Z

Vincent Ramos :

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' (AÉ ou encore ''extended attributs'', EA) qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour ajouter ou donner un attibut, on utilise la commande suivie de <code>+</code> et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que le ou les attributs mentionnés :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

Noter que ''ls'' n'indique pas la présence éventuelle d'attributs étendus et que ''find'' ne peut rechercher des fichiers selon ce critère.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignorent.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple, mais une application comme ''star''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T09:20:33Z

Vincent Ramos : /* Sauvegarde des données */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour ajouter ou donner un attibut, on utilise la commande suivie de <code>+</code> et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que le ou les attributs mentionnés :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

Noter que ''ls'' n'indique pas la présence éventuelle d'attributs étendus et que ''find'' ne peut rechercher des fichiers selon ce critère.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignorent.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple, mais une application comme ''star''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2005-10-28T09:16:09Z

Vincent Ramos : /* Noyau */ typo

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichiers ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Discussion:Gestion des ACL

2005-10-28T09:11:58Z

Vincent Ramos : → Mike-m

Petite question: ne devrait-on pas dire "une ACL" vue qu'il s'agit d'une liste de contrôle d'accès ? [[Utilisateur:Fred|Fred]]
:Je me suis posé la question : vu qu'il s'agit d'un(e) ''Acces Control List'' et qu'il n'y a pas de genre en anglais (dans ce cas de figure-là), il n'y a pas de réponse toute faite, à moins de se dire qu'on va l'utiliser au féminin parce qu'il y a un lien évident qu'on peut faire entre ''List'' et ''liste''.
:Dans ce cas, c'est un choix qui ne repose sur rien de grammatical mais sur une impression d'euphonie. Si le féminin te semble plus compréhensible, il n'y a qu'à changer. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 11:24 (CEST)
::petite remarque, on dit aussi bien "un gui" que "une gui" (google référence des milliers de page pour ces deux expressions), personnellement je suis un partisant du "une gui" car interface c'est un mot féminin --[[Utilisateur:Mike-m|Mike-m]] 28 oct 2005 à 05:24:46 (CEST)
:::J'avais entre temps changé tous mes ''un ACL'' en ''une ACL''. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 28 oct 2005 à 11:11 (CEST)

Attributs étendus

2005-10-28T01:28:41Z

Vincent Ramos : /* chattr */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour ajouter ou donner un attibut, on utilise la commande suivie de <code>+</code> et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que le ou les attributs mentionnés :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

Noter que ''ls'' n'indique pas la présence éventuelle d'attributs étendus et que ''find'' ne peut rechercher des fichiers selon ce critère.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignorent.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T01:25:51Z

Vincent Ramos : /* lsattr */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

Noter que ''ls'' n'indique pas la présence éventuelle d'attributs étendus et que ''find'' ne peut rechercher des fichiers selon ce critère.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignorent.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Catégorie:Trucs Administration

2005-10-28T01:16:31Z

Vincent Ramos : liens et typo

[[Catégorie:Trucs]]
Tout sur l'administration sous Linux : les [[permissions|droits et les permissions]], les [[systèmes de fichiers]], les logs, etc.

Attributs étendus

2005-10-28T01:14:31Z

Vincent Ramos : /* ls, cp, mv */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignorent.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T01:14:19Z

Vincent Ramos : /* lsattr */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>, à la manière du codage des permissions pratiqué par ''ls -l'' (<code>-rw-r--r--</code>).

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''I'' (fichier dépendant d'un répertoire indexé par HTree), ''E'' (fichier dont la compression est erronée ; dépend directement de l'attribut ''<code>c</code>ompressed''), ''X'' (fichier compressé dont une partie des données brutes peut être consultée directement ; dépend de <code>c</code>) et ''Z'' (fichier compressé corrompu ; '<code>c</code>). Ce sont des valeurs non modifiables ajoutées automatiquement aux fichiers. Les trois dernières ne sont toujours pas implémentées.

===ls, cp, mv===
Les commandes classiques de listage, copie et déplacement ne gèrent pas les attributs étendus, soit qu'elles ne les affichent pas (''ls''), soit qu'elles les ignore.

===Sauvegarde des données===
Sauvegarder des données dotées d'attributs étendus ne peut se faire correctement que si :
* le système de fichiers de stockage gère lui-même les attributs ;
* le logiciel de sauvegarde est compatible avec les attributs.

Dans le second cas, il convient de ne pas utiliser ''cpio'', ''tar'' ou ''rsync'', par exemple.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2005-10-28T00:47:34Z

Vincent Ramos : /* Documents annexes */

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichiers ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Utilisateur:Vincent Ramos

2005-10-28T00:43:18Z

Vincent Ramos : /* Pages dont je détiens le copyright */

Vu que j'ai quelque peu laissé de côté Wikipédia (cf. [http://fr.wikipedia.org/wiki/Utilisateur:Vincent_Ramos ma page là-bas]) parce qu'elle me prenait tout mon temps, je pense que je pourrai contribuer un peu à ce wiki.

Présentation dans les grandes lignes (pour les amateurs du genre, consulter ma page d'utilisateur chez Wikipédia) :
* je pratique plusieurs wikis depuis longtemps et suis administrateur de la Wikipédia francophone ; j'en ai installé un (mediawiki) sur mon serveur web/mail privé : je pense donc pouvoir rapidement m'adapter à celui-ci ;
* je suis administrateur du réseau externe de l'établissement scolaire où j'enseigne : j'en ai monté le projet de mise en place avec un collègue et fais actuellement tourner (et administre à distance par SSH) un serveur web sous Debian (Apache, PHP, MySQL pour un site sous SPIP dont je suis aussi administrateur/rédacteur), et mail (Exim4/uw-imap) ; je m'occupe de la sécurité de ce serveur, j'ai un accès administrateur au réseau interne et suis le « collègue-qui-sait-tout-en-informatique » de service ;
* comme je suis aussi enseignant (je pratique les lettres classiques : français, latin, grec ancien) et aime mon métier, je pense savoir expliquer (ou au moins vouloir expliquer) des notions complexes de manière à ce que la majorité les comprennent. Enfin, passionné de grammaire et d'histoire de la langue française que je suis, je crois savoir rédiger correctement et dans un français lisible.

Ce sera tout pour ma présentation.
==Pages dont je détiens le copyright==
... et dont je me considère être l'auteur principal. Les pages qui me sont attribuées sont publiées en GNU-FDL.
* [[Gestion des ACL]] ;
* [[attributs étendus]] d'''ext2'' et ''ext3''.

[[Utilisateur:Vincent Ramos|Vincent Ramos]] 24 oct 2005 à 22:59 (CEST)

Attributs étendus

2005-10-28T00:41:59Z

Vincent Ramos : /* Types d'attributs */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent des options de montage <code>mount -o sync</code> et <code>mount -o dirsync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>.

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''E'', ''I'', ''X'' et ''Z''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T00:41:05Z

Vincent Ramos : /* Types d'attributs */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Les données des répertoires et fichiers concernés sont mises à jour dès qu'une modification a eu lieu (et non en différé, comme c'est le cas par défaut pour ''ext2'' et ''ext3''). C'est l'équivalent de l'option de montage <code>mount -o sync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>.

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''E'', ''I'', ''X'' et ''Z''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T00:38:48Z

Vincent Ramos : /* Types d'attributs */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D), « mise à jour synchone des répertoires »
;synchronous updates (S), « mise à jour synchrone »
:Ces deux attributs ont un effet similaire. Le premier sert aux répertoires, le second aux fichiers. Ceux qui portent cet attributs sont mis à jour dès qu'une modification a eu lieu. C'est l'équivalent de l'option de montage <code>mount -o sync</code> (qu'on peut aussi passer dans ''fstab'') mais pour une sous-partie de l'arborescence et non la partition entière.
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>.

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''E'', ''I'', ''X'' et ''Z''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-28T00:17:58Z

Vincent Ramos : /* Types d'attributs */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)
;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A), « pas de mise à jour de la date de dernier accès »
:À chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de ''news''), ces modifications peuvent ralentir le système.
:Donner à un fichier l'attribut ''no atime updates'' permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (<code>mount -o noatime</code>), option que l'on peut inscrire dans [[fstab|/etc/fstab]].
;synchronous directory updates (D)
;synchronous updates (S)
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>.

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''E'', ''I'', ''X'' et ''Z''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-27T22:50:55Z

Vincent Ramos : /* lsattr */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)

;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A)
;synchronous directory updates (D)
;synchronous updates (S)
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===
Cette commande fonctionne comme ''ls'' et prend les options <code>-R</code> (listage récursif), <code>-a</code> (tout afficher) et <code>-d</code> (lister les répertoires comme des fichiers), entre autres ; ''lsattr'' peut afficher des attributs qu'on ne peut modifier avec ''chattr''

L'affichage est simple : chaque attribut du fichier est représenté par son code, une absence d'attribut l'étant par un <code>-</code>.

Ainsi :
<code>chattr +ASacDdijsTtu fichier
lsattr fichier
suS-iadAc----j-tT fichier</code>
L'attribut <code>D</code> n'a pas été appliqué, puisque le fichier n'est pas un répertoire.

Les autres valeurs que peut indiquer ''lsattr'' s'intercalent dans les espaces vacants : ''E'', ''I'', ''X'' et ''Z''.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-27T22:20:04Z

Vincent Ramos : /* Commandes */

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="alert">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="note">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs (dont root, qui peut cependant annuler ces attributs) quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont encore expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.
;append only (a), « ajouter seulement » ─ ''réservé à root''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compressé » ─ ''expérimental''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande de sauvegarde ''dump'' (qui ne fonctionne que pour ''ext2'' et ''ext3''). Cet attribut est utile pour empêcher la sauvegarde par ''dump'' d'un fichier ou répertoire situés dans un système de fichiers monté avec l'option <code>dump</code> positionnée à <code>1</code> (cf ''[[fstab]]'').
;immutable (i), « immuable » ─ ''réservé à root''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ ''réservé à root''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ ''expérimental''
:Un fichier portant cet attribut est non seulement « effacé » mais en plus les blocs qu'il occupait dans le système de fichiers sont recouverts de zéros pour éviter qu'on puisse récupérer les données malgré l'effacement.
:Normalement, effacer un fichier consiste seulement à détruire toute référence vers l'espace occupé par les données de ce fichier dans la partition. Il n'est cependant pas question de détruire physiquement les données elles-mêmes, sauf si le fichier possède cet attribut, auquel cas non seulement il n'est plus accessible mais en plus tous ses bits sont réécrits.
;no tail-merging (t)

;undeletable (u), « ineffaçable » ─ '''expérimental'''
:Lors d'un effacement, les références vers l'espace du système de fichiers qui contient les données sont détruites, mais pas les données. Sans ces références, cependant, l'espace anciennement réservé peut être utilisé par des fichiers nouvellement créés ou ayant été augmentés. Dans ce cas, il n'est plus possible de récupérer les données en question.
:L'attribut « ineffaçable » permet de préserver les blocs qui contenaient les données de façon à ce qu'on puisse les récupérer si besoin est. L'espace-disque n'est donc pas libéré.
;no atime updates (A)
;synchronous directory updates (D)
;synchronous updates (S)
;top of directory hierarchy (T), « répertoire racine » ─ ''réservé à root''
:Cet attribut indique au répartiteur de blocs Orlov (ou ''[http://lwn.net/Articles/14633/ Orlov block allocator]'', utilisé par le noyau Linux pour les systèmes de fichiers ''ext2'' et ''ext3'' depuis la version 2.5.46) que le répertoire concerné doit être considéré comme un répertoire racine de la hiérarchie des répertoires.
:L'allocateur de blocs est un processus propre au système de fichier permettant de répartir les blocs de données des fichiers dans l'espace disponible tout en garantissant une qu'il ne se produira pas une trop grande fragmentation. Pour cela, on place généralement dans un même groupe de cylindres du disque dur les blocs de fichiers dépendant d'un même répertoire. Dans le cas contraire, les données risquent d'être éparpillées, voire fragmentées (les blocs d'un même fichier sont alors répartis sur plusieurs cylindres non contigus). On ne peut cependant prévoir à l'avance de quel espace aura besoin un répertoire racine. Il pourrait ne contenir que peu de fichiers ou, au contraire, une arborescence complète et chargée. Le répartiteur Orlov prend donc soin d'éloigner le plus possible les uns des autres les répertoires racines, pour qu'ils disposent d'un espace suffisant où croître.
:Ajouter cet attribut à un répertoire permet au répartiteur de le traiter comme un répertoire racine, même s'il n'en est pas un, et de le placer loin des autres répertoires racines. Il est donc utile avec des sous-arborescences de fichiers complexes et lourdes qui risqueraient d'être fragmentées.

==Commandes==
ll existe deux commandes pour accéder aux attributs étendus : ''lsattr'' (''list attributes'', « lister les attributs ») ''chattr'' (''change attributes'', « changer les attributs »). Toutes deux sont incluses dans le paquetage ''e2fsprogs''.

===chattr===
Cette commande s'utilise quasiment comme un ''chmod'' simplifié : en effet, les attributs ne peuvent être indiqués que sous forme symbolique (dont les codes sont donnés ci-dessus) et non au moyen d'un éventuel nombre octal.

Ainsi, pour donner un attibut, on utilise la commande suivie de + et du code ; par exemple, rendre un fichier « immuable » se fait avec la commande (en root) :
<code>chattr +i fichier
</code>

Retirer un attribut requiert l'opérateur <code>-</code>. La commande pour enlever l'attribut « immuable » est donc :
<code>chattr -i fichier
</code>

Enfin, pour faire en sorte qu'un fichier n'ait que l'attribut « immuable » :
<code>chattr =i fichier
</code>

La commande peut être utilisée de manière récursive au moyen de l'option <code>-R</code> : pour rendre toute une hiérarchie immuable, il suffit de :
<code>chattr -R + i répertoire/
</code>

===lsattr===

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-27T22:09:40Z

Vincent Ramos : /* Commande */

Attributs étendus

2005-10-27T22:09:09Z

Vincent Ramos : /* Commande */

Attributs étendus

2005-10-27T16:10:56Z

Vincent Ramos : /* Types d'attributs */

Attributs étendus

2005-10-27T16:08:09Z

Vincent Ramos : /* Types d'attributs */

Attributs étendus

2005-10-27T15:43:33Z

Vincent Ramos : /* Types d'attributs */ Suite

Attributs étendus

2005-10-27T15:17:44Z

Vincent Ramos : /* Types d'attributs */

Attributs étendus

2005-10-27T14:45:58Z

Vincent Ramos : /* Types d'attributs */ mise en page

Attributs étendus

2005-10-27T14:44:52Z

Vincent Ramos : /* Types d'attributs */ mise en page

Attributs étendus

2005-10-27T14:43:12Z

Vincent Ramos : /* Types d'attributs */ Suite

Gestion des ACL

2005-10-27T14:09:18Z

Vincent Ramos : retouches

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. La gestion des ACL sous GNU/Linux s'inspire de la norme POSIX 1003.1e (projet 17) mais ne la respecte pas entièrement.

Au moyen des ACL, on peut étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. On peut aussi utiliser les ACL avec les systèmes de fichiers ''IBM JFS'', ''ReiserFS'', ''SGI XFS'' et ''NFS''. Leur implémentation peut nécessiter de patcher le noyau. Noter que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' qui ne gèrent aucun type de permissions.

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichier ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-27T14:01:08Z

Vincent Ramos : /* Types d'attributs */ Suite

Attributs étendus

2005-10-27T10:08:30Z

Vincent Ramos : /* Mise en place */ - agressif

Lea Linux:Rapport d'erreurs

2005-10-27T09:50:41Z

Vincent Ramos : /* Aide et cache */

== Bogues ==
* [[Lea_Linux:Rapport_d'erreurs/Problèmes]]
* [[Lea_Linux:Rapport_d'erreurs/Corrigés]]

== Journal des changements ==
Voir : [[Lea_Linux:Journal_des_changements]]

== Demandes de fonctionnalités ==

* export xhtml(urgent), odt, docbook(facultatif)
* import auto xhtml(urgent), odt, docbook(facultatif)
* Utiliser automatiquement l’identifiant du phorum (Note de Fred: c'est dans ''ma'' todolist)
* (jiel) aggrandir le textarea de la fenêtre d'édition, ce serait plus pratique pour l'édition ou la modif d'articles. (Note: C'est déjà possible, il suffit d'éditer tes préférences -- non testé)
* Un truc de fou : voter pour des trucs / astuces / fiches (karma) et avoir une page spéciale qui fait le top --[[Utilisateur:Mike-m|Mike-m]] 25 oct 2005 à 09:14:25 (CEST)

==Questions diverses==
===[[Café du coin]]===
*Bon, je parlais à [[Utilisateur:Ennael|ennael]] y'a pas deux minutes, et je lui disais qu'il serait peut-être pas mal d'avoir un [[Café du coin]] pour les échanges directs entre personnes (vu que je n'ai toujours pas compris comment on savait qu'on avait un message à part en regardant direct sa page de discute ou en suivant de près les modifs récentes).
*Question afférente : Y'a t'il un espace de nom Léa-Linux genre, [[Léa-Linux:Tagada]] comme l'espace d'aide, dans lequel on pourrait mettre cette page/forum qui serait alors [[Léa-Linux:Café du coin]]. [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:19 (CEST) Je réponds toute seule à ma question. Oui, l'espace est Lea Linux:, nous aurions donc : [[Lea Linux:Café du coin]]. [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:42 (CEST)

===[[Aide:Aide|Aide]] et cache===
Je veux bien me dévouer pour faire une page "premiers pas" de découverte wiki (oeuf corse, pompée sur wp ;-) ) dédiée à ce wiki et ses fonctionalités bizarres. Le système de cache, par exemple, je n'ai 1) pas tout compris 2) c'est méchamment déroutant pour les gens qui connaissent bien mediawiki dans sa version de base.
voilou [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:19 (CEST)
:ça me parait une très bonne idée (le café du coin ET la découverte de mediawiki), pour une explication du cache: je dois être mauvais pédagogue ;-p [[Utilisateur:Fred|Fred]] 26 oct 2005 à 15:58 (CEST)
::Honnêtement, je ne dirais pas que tu es mauvais pédagoque : c'est assez déroutant ce cache quand on est déjà habitué à Mediawiki. On s'y fait rapidement cependant et je trouve l'idée (et le module pour Mediawiki) très intéressante : c'est par exemple dix fois plus simple que la modération à la SPIP, qui, finalement, me semble terriblement lourde à gérer.
::Delphine : si tu as le courage de te lancer dans l'aide et un café du coin, je t'encourage vivement : le wiki manque encore de structuration et, surtout, de place centrale où échanger nos idées. J'ai cherché en vain un tel lieu (et me suis dit que j'allais le créer, sans en prendre le temps), et c'est important. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 27 oct 2005 à 11:50 (CEST)

Lea Linux:Modération/Aide à la modération

2005-10-27T02:38:53Z

Vincent Ramos : /* Modération sur le wiki de Léa */ ortho

= Principe de modération sur Léa =
Médiawiki n'a aucune connaissance d'une quelconque modération. C'est contraire au principe qui sous-tend mediawiki. Nous avons donc développé un cache statique pour Léa qui sert aussi à permettre la modération (et donc la validation ou l'invalidation des modification des pages par les utilisateurs de Léa). Il fonctionne de la manière suivante.

Le cache commence vide (assez classique en somme...)

Le serveur apache de Léa reçoit une demande de page, par exemple <nowiki>http://lea-linux.org/cached/index/Accueil.html</nowiki>, il vérifie que cette page est présente dans le cache statique.
* Si c'est le cas, il l'affiche et ne consulte pas mediawiki pour savoir si la page a été modifiée ou autre
* Si ce n'est pas le cas, il demande à mediawiki de générer la page, et la stocke si besoin dans le cache. Si la page est décrété par le serveur comme devant être cachée, toute modification ultérieure de la page par mediawiki sera invisible, vu que l'on tombera dans le premier membre de l'alternative.

Il existe pour éviter le cache, un partie "non-caché" de Léa, elle est disponible via, la petite clé anglaise en haut à droite de toutes les pages. Cliquer sur ce lien suppose qu'on a créé un compte mediawiki (et éventuellement que l'on a obtenu des administrateurs de Léa les droits idoines). C'est dans cette partie que se passe la gestion du cache et de la modération des pages.

= Modération sur le wiki de Léa =
On accède à la page permettant la modération sur Léa en cliquant sur la lien <code>Modération</code> disponible lorsque l'utilisateur actuellement loggué en a les droits.
: <border>[[Image:modero-bouton.jpg]]</border>
On arrive alors sur la page :
: <border>[[Image:modero-menu.jpg]]</border>
* Le bouton <key>Actualise l'affichage</key> est un lien vers la page principale de modération.
* Le bouton <key>Nettoyage du cache</key> permet d'effacer les fichiers du cache qui n'empêchent pas la modération.
* Le bouton <key>Relire la liste des fichiers</key> supprime le cache de la liste de fichiers (qui permet un accès plus rapide à la modération, au prix de possibles erreurs dans la liste)
Si on recherche une page précise dans le cache, on peut cliquer directement sur la barre de navigation (plutôt que de parcourir page après page la liste des articles).
:<border> [[Image:modero-navigation.jpg]]</border>

= Les différentes catégories de page =
Dans le cache de Léa on trouve trois sorte de pages :
* les page dont le cache est à jour (c'est à dire que la version qui est stockée dans la base de donnée de mediawiki est la même que celle qui a servi a générer la page actuellement dans le cache. Ces page sont visibles de cette façon :<br /> <border>[[Image:modero-cache-ajour.jpg]] </border><br /> Le nombre de pages dépendantes dans le cache indique le nombre de page nécessaire dans le cache pour simuler le caractère dynamique (il peut y avoir beaucoup de pages dépendantes : une page par révision de la même page, une page historique, etc.) ;
* les pages qui n'ont pas de date de révision :<br /> <border>[[Image:modero-no-rev.jpg]] </border><br /> Ces pages sont en fait les pages qui sont dans le cache et dont le programme gérant la modération n'a pas trouvé de correspondance dans la base de données. Normalement les pages dans le cache se trouvent forcément dans la base, mais la modération sur Léa est encore au stade "pre-alpha" ;
* les pages qui n'ont pas encore été modérées (c'est à dire qui n'ont pas été validée par un modérateur) :<br /> <border>[[Image:modero-non-moderees.jpg]] </border><br />.

= Effacer une page du cache =
Un modérateur peut décider d'effacer une page du cache pour différentes raisons (le programme pre-alpha n'a pas dédecté correctement une dépendance, etc ...). Il suffit de cliquer sur les liens <code>(rm)</code> (oui, oui comme la commande <code>rm</code> du shell). On lui demande alors confirmation :
:<border>[[Image:modero-confirme-efface.jpg]] </border>
Après confirmation, le programme confirme qu'il a bien effacé la page en question :
:<border>[[Image:modero-efface.jpg]]</border>

= Modération des pages =
Avant de valider une page, le modérateur doit vérifier que les modifications effectuées ne sont pas un tissu d'aneries (si, si ça arrive), en cliquant sur le bouton : <code>(diff)</code> qui affiche les différences entre la version qui est dans le cache et la version telle qu'elle a été modifiée :
:<border>[[Image:modero-diff.jpg]]</border>
Si les modification sont acceptables, on clique sur le bouton <code>[Accepter]</code> qui affiche alors :
: <border>[[Image:modero-accept-modif.jpg]]</border>

Si on ne veut pas accepter telle quelle les modifications, on peut soit révoquer les modification de l'utilisateur sur cette page (mais attention, il peut arriver que l'on efface en même temps des choses qui sont dans la page du cache. En effet, mediawiki ne peut révoquer des modification que par "lots" : correspondants à toutes les modifications ''récentes'' d'un utilisateur.

Dans un certain nombre de cas, on préférera peut-être éditer la page, soit pour en corriger une partie litigieuse, soit pour effacer une petite partie de la page.

= Statistiques du cache =
La page de modération affiche aussi quelques statistiques à propos du cache.
: <border>[[Image:modero-stats.jpg]].</border>
La différences entre « pages » et « fichiers » est importante. Chaque page de mediawiki peut être présentes de multiples fois dans le cache en tant que fichier (ce sont les pages dépendantes dont on a parlé plus haut).

= Aide à la modération et l'administration du wiki =
Trois pages sont particulièrement utiles pour vérifier l'état des pages de Léa :
* [[Special:BrokenRedirects|Redirections cassées]] : permet de trouver les pages dont la redirection pointe dans le vide,
* [[Special:DoubleRedirects|Doubles redirections]] : permet de trouver les pages dont la redirection pointe vers une redirection et donc dont la redirection n'est pas transparente,
* [[Special:Wantedpages|Pages les plus demandées]] : permet de trouver les pages vers lesquelles des liens du wiki aboutissent mais qui n'existent pas, souvent : une erreur de lien dans la page inititale

Lea Linux:Rapport d'erreurs

2005-10-27T02:33:05Z

Vincent Ramos : Ortho

== Bogues ==
=== À régler ===
* [[Utilisateur:Vincent Ramos|Vincent Ramos]] 27 oct 2005 à 04:33 (CEST) Corriger ''page précédante'' en ''page précéd'''e'''nte'' dans la page de modération. Pour la même page, je suggère une plus grande cohérence en mettant tous les verbes à l'infinitif et autres : « Gère'''r''' la modération sur Léa, Effacer le cache, Actualise'''r''' l'affichage, '''Vider le''' <s>Nettoyage du</s> cache, Afficher les modérations, '''Actualiser''' <s>Relire</s> la liste des fichiers, Aide ». Je ''suggère'', hein, je ne voudrais pas passer pour un affreux.
* [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 14:51 (CEST) En passant, il y a aussi un bug avec <nowiki>'''</nowiki>, que j'ai dû remplacer par <nowiki><b></b></nowiki> dans le paragraphe indenté par <:> précédent.
*: peut-être mais là, je n'y peux rien : doit falloir patcher mediawiki et je ne m'en sens pas capable de suite
*[[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 26 oct 2005 à 00:08 (CEST) Bogue de css je pense. Le style de lien dans un titre prend le pas sur la balise titre et donc la police est plus petite. Pas bô. Voir plus bas ma section intitulée Aide et cache.
*[[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 26 oct 2005 à 00:06 (CEST) orthographe : le "contribution de l'tilisateur" qui devrait dire "contribution'''s''' de l'utilisateur". amha.
* (Jiel) 24 oct 2005 à 15:44 (GMT) http://lea-linux.org/cached/index/ModÃšle:Fiches:plan-internet.html ne modifie pas http://lea-linux.org/cached/index/Fiches:Index.html
*: problème lié au cache, connu : faut effacer du cache les pages dépendant de chaque modèle, pour faire mieux, faudrait attaquer la DB mediawiki et franchement ça me gave de toutes façon : on videra le cache de temps en temps pour remettre tout à plat.
* [[Utilisateur:Anguy|Anguy]] 24 oct 2005 à 09:39 (CEST) : Une probable erreur du moteur de recherche, par exemple avec le terme "VNC" qui renvoie 0 article alors qu'il devrait au moins afficher cette page [[http://lea-linux.org/cached/index/Reseau-resau_plus-vnc.html# VNC]]
*: c'est effectivement un bug du moteur, il jette les mots de moins de 3 lettres dans la recherche (je ne sais si c'est médiawiki ou la rechercher fulltext de mysql et sa configuration)
* (JeanEtienne) Autre problème (?) du moteur de recherche : lorsque je ne suis pas connecté (a priori, c'est le cas de l'utilisateur lambda qui débarque) et que je veux effectuer une recherche, je rempli la case adéquate. Mais que je clique sur le bouton "Consulter" ou "Rechercher", il me renvoie une erreur : "Nom d'utilisateur nécessaire", "Vous devez vous connecter pour voir les autres pages". Par contre, toujours non connecté, je peux tout consulter en suivant les liens "Le réseau" -> "Se connecter" -> ... Est-ce une fonctionnalité voulue ou bien un petit bug de jeunesse ? En tous cas, je trouve (AMHA) le message d'erreur peut engageant.
* (Mike-m) l'éditeur est trompeur, pour faire un lien interne il propose la syntaxe <code>[[Lien Titre]]</code> alors que c'est <code>[[Lien|Et le titre]]</code>
*: je ne peux rien y faire (sans patcher mediawiki, donc je ne le ferait pas) : ils n'ont prévu qu'un message pour les liens externes/internes alors que la syntaxe est différente
*:: Merci Fred, je m'en doutais qu'il fallait hacker le source, il est peut être bon que ce soit signalé après tout
* (Jiel) j'ai pas trouvé la rubrique détente (http://lea-linux.org/detente/), elle a été migré? Pas trouvé en cherchant avec les url non plus (http://devel.lea-linux.org/nocache/index/Detente-index.html). J'ai mal cherché? Bon je sais c'est pas une rubrique ultra utile mais bon ;-)
*: effectivement (mais ce n'est pas ma priorité) [[Utilisateur:Lea|Lea]] 13 oct 2005 à 14:26 (CEST)
*:: (Jiel) je devine mais c'était juste pour le signaler :)
*::: http://devel.lea-linux.org/detente/ (-:
* je n'ai pas retrouvé mon t&a sur la livebox http://lea-linux.org/trucs/item.657.html . est-ce qu'ils ont tous été migrés ? [[Utilisateur:LeaJice|LeaJice]] 19 oct 2005 à 13:42 (CEST)
*: il doit y en avoir une 20{{exp|aines}} qui n'ont pas migré pour diverses raisons (assez obscures : je n'ai pas cherché, il semblerait que ce soit des problèmes d'utf8 ou un truc du genre) : bref faudra les faire à la mano
* problème de traduction : tous les messages de médiawiki ne sont pas traduits, certains sont MAL traduits, merci de signaler ici les problèmes rencontrés.
** Certaine URL n'ont pas été traduite correctement comme ici, je ne sais comment corriger : http://devel.lea-linux.org/cached/index/Intro-d%C3%A9marrage.html#Au_secours_.21 et plus généralement cette page (je n'ai pas encore été voir d'autre pour le moment) [[Utilisateur:YannTech|YannTech]] 16 oct 2005 à 20:51 (CEST)
**: je suppose que tu parles des liens du type :
**:*[../trucs/lire.php3?id=xxxx ...] il faut les transformer en : <nowiki>[[Trucs:Oldid=xxxx|...]]</nowiki>
**:*[../logi/lire.php3?id=xxxx ... ] il faut les transformer en : <nowiki>[[Logithèque:Oldid=xxxx|...]]</nowiki>
**:*[../driver/lire.php3?id=xxxx ... ] il faut les transformer en : <nowiki>[[Driver:Oldid=xxxx|...]]</nowiki>
**:*[../annuaire/lire.php3?id=xxxx ... ] il faut les transformer en : <nowiki>[[Annuaire:Oldid=xxxx|...]]</nowiki>
**:*[../trucs/?aff_item=xxxx ...] il faut les transformer en : <nowiki>[[Trucs:Oldid=xxxx|...]]</nowiki>
**:*[../logi/?aff_item=xxxx ... ] il faut les transformer en : <nowiki>[[Logithèque:Oldid=xxxx|...]]</nowiki>
**:*[../driver/?aff_item=xxxx ... ] il faut les transformer en : <nowiki>[[Driver:Oldid=xxxx|...]]</nowiki>
**:*[../annuaire/?aff_item=xxxx ... ] il faut les transformer en : <nowiki>[[Annuaire:Oldid=xxxx|...]]</nowiki>
**: Pour les pages avec "rub" remplacer les Oldid des liens précédants par "Oldrub"
** De même pour les URL en [/software/toms1.php3 article sur la distribution TOMSRTBT] que faire ?
* il semblerait que l'extension "rss" qui permet de d'inclure des rss parte plus ou moins en vrille... je pense utiliser un script de récupération des rss dans la crontab
** Je n’ai rien remarqué de spécial, qu’est-ce qui ne va pas ? [[Utilisateur:Nicola|Nicola]]
** Lorsque la page doit être recréée, parfois, elle met un temps infini à se recharger (mais c'est loin d'être régulier : en tout cas, j'ai plus eu ce pb depuis que j'ai supprimé les lien "<nowiki><rss></nowiki>")
* problèmes avec les catégories [[Special:Categories]]
** quel contenu mettre dans les pages de catégorie ? (Note de Fred: laissons faire le temps)
* export autre (ODT, xhtml, docbook?) (pas urgent)
* css "printable" (urgent)
* correction/suppression des pages "daubé"
* que faire de nawak
-> (jice) tu parles des docs ou du logiciel ? pour les docs, elles ne sont pas importées,
et le logiciel ne va plus servir, donc je répondrais : rien ;-)
* sur la gauche le ''Découvrez et contribuez à Léa'' (juste en dessous du pavé ''Accueil - user - créer un compte - version imprimable | pdf - aide'') sort du cadre (Firefox 1.5 beta 1)
* le ''changelog'' bureaucrate ne montre pas le statut acquis
* Les pdf récupérés via le menu à gauche ne sont pas lisibles dans Acrobat Reader 7 sous Window$. Sous gsview on a droit à une page blanche ... (encore non testé avec Xpdf) ! [[Utilisateur:AlSim|AlSim]] (23 oct 2005 - maj le 24)
:: bug de médiawiki : faire un rapport de bug à médiawiki ...
* FIXÉ : [[Utilisateur:Vincent Ramos|Vincent Ramos]] 25 oct 2005 à 13:30 (CEST) : le logo devrait être encadré par un lien qui ramène à l'accueil.
*:(Anne) encadré je ne sais pas mais le lien sur le logo oui je pense aussi
*::Quand je dis ''encadré'', c'est par une balise <code><a></code> et non une bordure. Je n'étais pas clair. [[Utilisateur:Fred|Fred]] 26 oct 2005 à 15:55 (CEST)
*:([[Utilisateur:Fred|Fred]] 26 oct 2005 à 00:52 (CEST)) fait (sur les pages qui seront regénérées)

=== Réglés ===
* [[Utilisateur:Fred|Fred]] 26 oct 2005 à 22:33 (CEST) : corrigé
*: [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 14:51 (CEST) : l'orthographe du message d'avertissement lors d'une modification (normalement [[MediaWiki:Copyrightwarning]] ou [[MediaWiki:Copyrightwarning2]] mais cela ne semble pas le cas dans cette mouture du wiki : [[Utilisateur:Fred|Fred]]: non pour des raisons de vitesse on n'utilise pas la base de donnée pour lire les messages mais le tableau - c'est une option de mediawiki, d'après les développeur on gagne 20 à 60% de temps de calcul par page )
* ([[Utilisateur:Fred|Fred]] 26 oct 2005 à 10:28 (CEST)) réglé :
*[[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:38 (CEST) Quand je clique sur la page de Vincent (qui pourtant semble avoir quelque chose dessus, je suis renvoyée à la page d'accueil ? quid ? Pas vrai avec les autres.
*: Le bug est vraiment vicieux ... si on met "Vinc" en n'importe quelle position du nom de page on est redirigé vers l'accueil ... je cherche mais ne comprends pas ... exemple : [[BlaVincBlabla]] mais pas (enfin j'ai pas encore trouvé d'autres chaines qui le fond) avec autre chose que "Vinc" ... vraiment très étrange.
*::Cela n'arrive qu'avec la version en cache du site : j'imagine que c'est une histoire de page qui ne peut être servie (problème de cache ?), d'où un 404 avec redirection vers la racine du site, non ? Ce bug n'apparaît pas dans la version non cachée. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 02:57 (CEST)
*::: oui j'ai remarqué cela aussi, c'est trés étrange, si je supprime le .htaccess contenant des rewrite rule c'est quand même redirigé vers l'accueil (normal aucune règle ne devrait matcher Vinc à cet endroit de l'url) et si en plus je remplace le 404.php qui gère le cache lui-même, la redirection a lieu quand même ... ça me laisse plus que perplexe (surtout, ce qui m'étonne, c'est pas que j'ai pu merdé un truc : ça je suis spécialiste, c'est que ça arrive qu'avec "Vinc" pourquoi donc "Vinc" ? J'ai absolument aucune piste
*:::: encore plus étrange: sur devel.lea-linux.org et lea-linux.org il y a en ce moment exactement le même site (lien symbolique vers le même rep pour les deux vhosts) et bien le comportement n'est pas le même, il revient au même (affichage de l'accueil) mais dans un cas via une redirection, dans l'autre affichage direct de la page Accueil semble-t-il sans redirection) ... je patauge dans la semoule.
*:::: on progresse, en fait c'est pas Vinc qui pose problème mais "inc" ... comme include ... une piste ? ou pas ? mystère ! [[Utilisateur:Fred|Fred]] 26 oct 2005 à 03:21 (CEST)
*:::::Waouh, quel jolie recherche de bug ! [[Utilisateur:Vincent Ramos|Vincent Ramos]] 26 oct 2005 à 11:28 (CEST)
*::::: trouvé ! c'était une erreur de la configuration d'apache un <code><Files ~ ".inc"></code> à la place d'un <code><Files ~ "\.inc$"></code>
* [[Utilisateur:keyes|keyes]]: Petit problème de syntaxe dans l'email de confirmation de création d'un compte. "Quelqu'un, probablement vous avec l' '''adresse email 82.xxx.xxx.xxx''', a enregistré un compte « Keyes » avec cette email sur le site Lea Linux." [...] Bien entendu il s'agit de l'adresse IP, pas de l'adresse email.
*: corrigé
* (mike-m) l'upload d'une image ne marche pas, à la place il me demande de me connecter, alors que je le suis déjà
*: il faut être éditeur ou plus pour pouvoir uploader des images. [[Utilisateur:Fred|Fred]] 23 oct 2005 à 22:32 (CEST)
*:: okidoki
* fait:
** amélioration de l'interface de modération (recherche par lettre de début, par page)
** amélioration de la vitesse de l'interface de modération (réduction de la charge serveur) : utilisation d'un cache pour les information de fichier, le répertoire de cache ne sera plus parcouru des 100aines de fois pour juste se promener dans les fichiers du cache.
* fait: ajouter en bas de chaque article les "autres ressources" des anciens articles
*: dans la mesure du possible (ie: j'ai pas cherché à la mano les tritres des articles, un certains nombres de ressources ~ 10, ont été mangées par médiawiki)
* Lorsque l'on est sur la page des contributions d'un utilisateur, il est affiché ''Contributions de $1'' au lieu du nom de l'utilisateur
*: Ce n'est pas un bug, mais il y a une faute de frappe dans les préférences utilisateur: Me prévenir par courrile des changements de ma page
* affichage correct du fait qu'on soit loggué ou pas : utilisation d'un morceau de code javascript (seule solution que j'ai trouvé, à cause du cache : qui rend certaine page statique alors qu'elles sont toutes dynamiques du point de vue de l'affichage de ce genre d'information). Ce code ne vérifie pas les mots de passe : il suppose que les cookies annoncés sont corrects et bien fixés par mediawiki, si ce n'est pas le cas et qu'un mec essaie de truander, et bien il se retrouve avec un affichage qui lui fait croire qu'il est vraiment loggué, même s'il ne l'est pas. Tant pis pour lui ;-p
* portage des commentaires de l'ancien wiki dans le nouveau (les pages ne sont certainement pas "trés" correctes, mais ça permettra de les relire
* lien "ajouter un commentaire en bas de chaque page" qui ajoute un truc à la page "discussion"
* maj mediawik 1.5rc4 -> mediwiki 1.5.0
* CSS / Skin LéaLinux : liens d'édition plus lisible + repositionnement des liens d'édition du ''bas''
* [[Utilisateur:Lea|Lea]] 3 oct 2005 à 17:20 (CEST) (réglé) (jiel) confirmation par courriel lors de la création de compte: quand je clique sur le lien pour confirmer, j'ai "The requested URL /cached/index/Special:Confirmemail/[lettresetchiffres].html was not found on this server.".
* 3 oct 2005 à 01:21 (CEST) Les "Fiches pratiques" n'affichent rien
** Ça m’étonnerait… lesquelles ?
** Moi rien ne m'étonne, mais par contre, je n'ai pas ce problème, de quelle fiche tu parles (url ?) et depuis quelles pages obtiens tu ces url ? (url ?)
** (jiel) Je pense qu'il veut dire en cliquant dans le menu dans la boite en haut du site, le lien est "http://devel.lea-linux.org/cached/index/Fiches:index.html#" au lieu de "http://devel.lea-linux.org/cached/index/Fiches:Index.html#" (juste la maj qui change en fait). Les fiches sont donc accessibles sur la page d'accueil en bas, mais pas dans la boite en haut.
** (fred) si c'est ça : alors c'est réglé ... je n'avais pas ce "pb" sur konqi, ça faisait une redirection automatiquement vers la bonne page ... étrange...
* (2 oct 2005 à 18:22 (CEST) réglé) Pour l'activation du compte, lorsque je clique sur l'url de confirmation une fenêtre de connexion s'affiche, mais il n'a pas l'air d'apprécier mon login/passwd (me réaffiche la fenêtre de login)
** note : pour activer le compte, il n'est rien besoin de faire : il est activé, d'ailleur tu as posté ce text VIA ce compte ce qui prouve que tu es bien enregistré ET que ton compte fonctionne
** par contre, la confirmation d'email ne semble pas fonctionner pour toi, puis-je te demander de m'envoyer, l'url qui est dans le mail de confirmation (mais avant, peux-tu recliquer dessus, je crois que je vois ou est le pb et j'espere que je viens de le corriger).
* je n’arrive plus à éditer ma page utilisateur (nicola), il dit que je ne suis pas connecté, même problème avec pas mal de pages spéciales (semble réglé)
* création de page (lien en rouge) qui bugue (il y a parfois un / en trop entre edit et index) (may be fixed)
* la balise ''code'' crée un retour à la ligne (fixed)
* problème avec les "?" dans les noms de pages (enfin j'espère)
* problème avec les login ne commençant pas par une majuscule : un ucfirst est fait pour éviter ce pb
* support d’utf-8 (si ce n’est pas déjà fait) : (note de fred: mediawiki est nativement en utf-8)
* contenu de l'index : [[Accueil]] à revoir (urgent) : ce n'est certes pas parfait, loin s'en faut, mais un appel à contribution est lancé.
* export PDF (urgent) : version partiellement satisfaisante (à améliorer, mais plus tard) accessible via le bouton "Version pdf".
* login sur nocache avec les identifiants mediawiki
* protection "fs-overflow" : les pages n'existants pas ne génére rien dans le cache
* le bouton admin swap de "cached" à "nocache"
* lien des deux menus à voir (urgent) (FIXED)
* le renommage de page ne fonctionne pas comme il devrait : la redirection qui suit le renommage renvoie sur la page d'Accueil plutôt que vers la bonne page (FIXED)
* dans le même ordre d'idée lors de l'upload d'une image, l'upload se fait bien mais la redirection qui suit l'upload merdoit. (FIXED)
* problème avec les pages a un titre (ou un namespace) comportant des caractères accentués -> après la preview, ces caractères sont remplacés par : %xy%zt etc ... et ça plante le "title" (FRED:FIXED / putain d'UTF-8 de mes deux !)
* problèmes avec les modèles (FRED:FIXED) :
** modification de la page Accueil car un modèle s'utilise pour la page <nowiki>[[Modèle:Nom du modèle]]</nowiki> avec le marqueur <nowiki>{{Nom du modèle}}</nowiki> (FRED:FIXED)
** un seul niveau de catégorie, il faut éditer les pages des sous-catégories pour les inclure dans sa catégorie mère => ajout de <nowiki>[[catégorie:nom de la catégorie mère]]</nowiki> dans la page de la catégorie (Note de Fred: je ne vois pas vraiment ce que tu veux dire) (ST:FIXED par exemple [Catégorie:Applications] appartient à [Catégorie:Léa_pour_les_pros])
** l'accès en lecture aux modèles en cache est interdit (demande d'identification infinie) et ainsi les modèles ne sont pas résolus pour affichage : peut-être dû au problème de cache et caractères accentués
** cf doc http://fr.wikipedia.org/wiki/Aide:Modèle
* problème avec les liens mails, comment écrire un lien mailto en MediaWiki ? (FRED:FIXED) comme ça : mailto:capue@labas.com et pour éviter que ça merdoie : <nowiki>[mailto:capue@labas.com un joli nom]</nowiki> donne : [mailto:capue@labas.com un joli nom]
* les sous sections, sous-sous sections etc... vautre le cache ex: [[Section/Page]] : FIXED (mais j'ai l'impression que les "rétro-lien" (ie: vers [[Section]] depuis [[Section/Page]] ne fonctionnent pas, pour une raison qui m'échappe.
* version imprimable fonctionnelle
* FIXÉ : [[Utilisateur:Vincent Ramos|Vincent Ramos]] 25 oct 2005 à 04:06 (CEST) : la police à utiliser pour les paragraphes sous <nowiki><code></code></nowiki> devrait être à chasse fixe (type Courier) et non proportionnelle. Pour certaines lignes de code, il y a des effets gênants (combien y a-t-il de traits d'union dans -- et --- ?) et dans la majorité des cas, c'est inesthétique. D'autre par, la taille de police par défaut est minuscule.
*: Peux-tu me montrer une page qui pose un problème ? Merci --[[Utilisateur:Mike-m|Mike-m]] 25 oct 2005 à 04:17:06 (CEST)
*::Par exemple, [[Gestion des ACL]], dont voici une [[:image:Lea_traits_d_union.png|capture d'écran]] sous Firefox sans réglages particuliers sous Debian. Noter le caractère peu clair de la première ligne de commande. De toute façon, quand je consulte Léa, je suis obligé d'augmenter de manière importante la taille des caractères. Je me demande ce que donne le site pour les mal-voyants. [[Utilisateur:Vincent Ramos|Vincent Ramos]] 25 oct 2005 à 11:12 (CEST)
*::: pour les mal voyants : le zoom est leur ami,
*::: pour le code, je viens mettre la police "courier, fixed" et j'ai supprimé le 90% de taille, (mais il faut reloader la page pour recharcher la CSS) ça devrait être plus lisible.
*::::La police en général est super fatigante sur mon écran. Et pas jolie du tout (sans anticrénelage, taille défaut trop grande ?) c'est très bizarre. C'est quoi comme police ?[[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]]

== Journal des changements ==
Voir : [[Lea_Linux:Journal_des_changements]]

== Demandes de fonctionnalités ==

* export xhtml(urgent), odt, docbook(facultatif)
* import auto xhtml(urgent), odt, docbook(facultatif)
* Utiliser automatiquement l’identifiant du phorum (Note de Fred: c'est dans ''ma'' todolist)
* (jiel) aggrandir le textarea de la fenêtre d'édition, ce serait plus pratique pour l'édition ou la modif d'articles. (Note: C'est déjà possible, il suffit d'éditer tes préférences -- non testé)
* Un truc de fou : voter pour des trucs / astuces / fiches (karma) et avoir une page spéciale qui fait le top --[[Utilisateur:Mike-m|Mike-m]] 25 oct 2005 à 09:14:25 (CEST)

==Questions diverses==
===[[Café du coin]]===
*Bon, je parlais à [[Utilisateur:Ennael|ennael]] y'a pas deux minutes, et je lui disais qu'il serait peut-être pas mal d'avoir un [[Café du coin]] pour les échanges directs entre personnes (vu que je n'ai toujours pas compris comment on savait qu'on avait un message à part en regardant direct sa page de discute ou en suivant de près les modifs récentes).
*Question afférente : Y'a t'il un espace de nom Léa-Linux genre, [[Léa-Linux:Tagada]] comme l'espace d'aide, dans lequel on pourrait mettre cette page/forum qui serait alors [[Léa-Linux:Café du coin]]. [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:19 (CEST) Je réponds toute seule à ma question. Oui, l'espace est Lea Linux:, nous aurions donc : [[Lea Linux:Café du coin]]. [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:42 (CEST)

===[[Aide:Aide|Aide]] et cache===
Je veux bien me dévouer pour faire une page "premiers pas" de découverte wiki (oeuf corse, pompée sur wp ;-) ) dédiée à ce wiki et ses fonctionalités bizarres. Le système de cache, par exemple, je n'ai 1) pas tout compris 2) c'est méchamment déroutant pour les gens qui connaissent bien mediawiki dans sa version de base.
voilou [[Utilisateur:Notafish|notafish]] [[Discussion Utilisateur:Notafish| }<';>]] 25 oct 2005 à 23:19 (CEST)
ça me parait une très bonne idée (le café du coin ET la découverte de mediawiki), pour une explication du cache: je dois être mauvais pédagogue ;-p [[Utilisateur:Fred|Fred]] 26 oct 2005 à 15:58 (CEST)

Gestion des ACL

2005-10-27T02:25:46Z

Vincent Ramos : /* Notes concernant la syntaxe de ''setfacl'' */

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. Les ACL sont conformes aux normes POSIX.

Au moyen des ACL, on peut donc étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. Noter au passage que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' (qui ne gère aucun type de permissions).

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Note concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichier ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2005-10-27T02:24:00Z

Vincent Ramos : /* Sauvegarde des données */

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. Les ACL sont conformes aux normes POSIX.

Au moyen des ACL, on peut donc étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. Noter au passage que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' (qui ne gère aucun type de permissions).

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Notes concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichier ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2005-10-27T02:23:05Z

Vincent Ramos : /* Sauvegarde des données */

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. Les ACL sont conformes aux normes POSIX.

Au moyen des ACL, on peut donc étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. Noter au passage que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' (qui ne gère aucun type de permissions).

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichiers pour le stockage qui soit compatible ;
* et l'utilisation d'un logiciel de sauvegarde qui soit tout autant compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>
setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Notes concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichier ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Gestion des ACL

2005-10-27T02:22:07Z

Vincent Ramos : /* ls, cp et mv */ Nouvelle section

[[Catégorie:Administration_système]]

Une '''ACL''', ou ''Access Control List'' (en anglais : « liste de contrôle d'accès ») est, pour définir simplement la notion, une liste de [[Admin-admin env-permissions|permission]]s sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques » (c'est-à-dire, techniquement, les permissions POSIX.1) de ce fichier. Ces permissions concernent des utilisateurs et/ou des groupes définis. Les ACL sont conformes aux normes POSIX.

Au moyen des ACL, on peut donc étendre le nombre d'utilisateurs et de groupes ayant des droits sur un même fichier. Rappelons que, dans le monde UNIX, chaque fichier ne peut normalement indiquer des permissions que pour ''un seul utilisateur'' et ''un seul groupe'', qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »). Avec les ACL, on peut (entre autres) ajouter à un fichier d'autres utilisateurs et groupes et définir leurs droits séparément. On se rapproche ainsi du système de permissions pratiqué sur les plate-formes NT (de nombreuses différences subsistent, cependant).

Les ACL sont très utiles (voire indispensables) dans des environnements informatiques axés sur le travail collaboratif et mutualisé ; de même, leur utilisation avec [[Reseau-partfic-samba|SAMBA]] permet d'en étendre les capacités.

<cadre type="note">Dans les exemples qui suivent, les commandes peuvent être tapées en root ou en utilisateur normal, selon la portée des modificaitons : pour modifier les droits d'un fichier qui n'est pas possédé par un utilisateur ou pour ajouter des permissions à un autre utilisateur ou encore pour ajouter aux ACL un groupe dont l'utilisateur ne fait pas partie, il faut être root (pour les utilisateurs Ubuntu, il faut préfixer les commandes par [[sudo|<code>sudo</code>]]).</cadre>

==Exemple pratique==
Soit un fichier ''/var/www/index.php'' (page d'index d'un site web, par exemple) dont les droits sont les suivants :
<code>ls -l /var/www/index.php
-rw-r----- 1 root www-data 18 2005-09-11 11:24 /var/www/index.php</code>

En d'autres termes, root en est le propriétaire ; il peut le lire et le modifier ; le fichier est aussi accordé au groupe ''www-data'' (celui sous lequel, par exemple, tourne le [[Reseau-web-Apache PHP MySQL|serveur web]]), dont les membres peuvent le lire mais pas le modifier. Quant au reste du monde, il ne peut pas y accéder (le fichier contient des informations confidentielles telles qu'un mot de passe à une base de données [[Reseau-web-Apache PHP MySQL|MySQL]]).

Imaginons qu'on veuille rendre le fichier accessible en lecture aux utilisateurs jean et luce, en lecture et écriture à khadija et alice. On pourrait à la rigueur faire entrer jean et luce dans le groupe ''www-data'' mais cela introduirait une faille de sécurité car ''www-data'' peut aussi accéder à des données qui ne les concernent pas. Il n'est en tout cas rationnellement pas prudent d'ajouter khadija et alice au groupe ''root''. On ne peut non plus changer les permissions (les mettre en lecture et écriture pour tout le monde) ou modifier le propriétaire et le groupe.

Les ACL sont là une solution pratique et facile à gérer dans ce cas ; il suffit d'ajouter des permissions à l'ACL du fichier (grâce à des commandes décrites plus bas) pour qu'il se présente ainsi :
<code>root: rw-
www-data: r--
khadija: rw-
alice: rw-
jean: r--
luce: r--
reste du monde : ---
</code>

==Mise en place==
Selon la version du noyau utilisée, le support des ACL peut ou non être déjà compilé. S'il l'est, il faut aussi que la partition contenant les fichiers dont on veut étendre les droits soit montée avec l'option idoine.

===Noyau===
Il faut d'abord savoir si le noyau a été compilé avec le support des ACL. Le plus simple est de le vérifier dans le fichier de configuration du noyau, fichier normalement situé sous ''/boot''. Pour ce faire, utiliser la [[Admin-admin env-shell|commande <i>grep</i>]] :
<code>$ grep ACL /boot/config-version-du-noyau
</code>

Elle doit renvoyer la ligne suivante :
<code>CONFIG_FS_POSIX_ACL=y
</code>
pour signaler que le support général des ACL est présent, et plusieurs lignes du type
<code>CONFIG_SystèmeDeFichiers]_FS_POSIX_ACL=y
</code>
où ''[[système de fichiers|SystèmeDeFichiers]]'' peut recevoir les valeurs (pour un noyau 2.6.8-2-386 à la date de rédaction) ''EXT2'', ''EXT3'', ''JFS'' et ''XFS''. Noter au passage que les ACL ne sont pas possibles avec des systèmes de fichiers comme ''vfat'' (qui ne gère aucun type de permissions).

Si la valeur des options n'est pas correcte, vous devez [[Rubrique : noyau et modules|recompiler votre noyau]]. N'oubliez pas de prévoir au moins un système de fichiers pour lequel les ACL seront permis.

===Systèmes de fichiers/montage des partitions===
Quand le noyau est disposé à gérer les ACL, on doit préparer les partitions montées dans un système de fichiers adapté (par exemple, il est exclu de vouloir utiliser ces permissions avec du ''vfat'').

====Montage et démontage à la volée====
Il faut monter les partitions voulues avec l'option ''acl''. Par exemple :
<code>mount -t ext3 -o defaults,acl /dev/hda2/ /var/www/
</code>
Si la partition est déjà montée, on peut modifier ses paramètres à la volée :
<code>mount -o remount,acl /var/www/
</code>

====Configuration automatique====
L'inscription dans ''[[Admin-admin fs-fstab|/etc/fstab]]'' des options de gestion des ACL est recommandée quand leur utilisation est régulière. Par exemple, notre même couple ''partition'' / ''point de montage'' serait déclaré ainsi :
<code>/dev/hda2 /var/www ext3 defaults,acl 0 0
</code>

À chaque montage automatique des partitions, le support des ACL sera activé.

==Commandes==
Il existe deux commandes essentielles : l'une pour manipuler l'ACL d'un fichier (''setfacl'') et l'autre pour la consulter (''getfacl''). Les commandes traditionnelles ''chmod'' et ''chown'' ne peuvent accéder aux ACL.

Ces deux commandes nécessitent, sous Debian (et distributions dérivées, comme Knoppix ou Ubuntu), l'installation du paquetage « acl ». Pour l'installer :
<code>[sudo] apt-get install acl
</code>
(ajout de <code>sudo</code> pour Ubuntu)

Pour les distributions à base de RedHat (donc aussi Fedora, Mandriva), il faut installer les paquetages <code>acl.*.rpm</code> et <code>libacl1.*.rpm</code> (leur nom contient leur numéro de version).

===setfacl===
Le nom de la commande se comprend ''set file's ACL'' (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (<code>man setfacl</code>). La commande fonctionne bien sûr aussi de manière récursive (option <code>-R</code>) :
<code>setfacl -Rm u:khadija:rw /var/www/
</code>
modifie l'ACL de tous les fichiers situés sous ''/var/www/'' en attribuant une permission de lecture et d'écriture à l'utilisateur khadija.

====Ajouter des permissions====
La syntaxe fondamentale est simple. La commande
<code>setfacl -m u:khadija:rw /var/www/index.php</code>
modifiera (<code>-m</code>) l'ACL de ''/var/www/index.php'' en attribuant à l'utilisateur (préfixe <code>u:</code>) khadija les droits <code>rw</code> et en lui refusant le droit d'exécution (qui n'a pas été mentionné dans la commande).

Les principaux paramètres à connaître sont :
* '''préfixes :'''
** <code>u:</code> (droits pour un '''u'''tilisateur, nommé ou désigné par son uid) ;
** <code>g:</code> (droits pour un '''g'''roupe, nommé ou désigné par son gid) ;
** <code>o:</code> (droits pour '''''o'''ther'', le reste du monde) ;
* '''permissions :''' elles sont codées dans l'ordre <code>r</code>, <code>w</code> et <code>x</code> ou <code>X</code> (ce dernier représentant, comme avec ''chmod'', le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur <code>x</code>). On les remplace par <code>-</code> pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction : <code>setfacl -m u:khadija:w /var/www/index.php</code> et <code>setfacl -m u:khadija:-w- /var/www/index.php</code> reviennent au même.

On peut construire des commandes plus complexes en enchaînant les entrées dans l'ACL :
<code>setfacl -m u:khadija:rw,g:site1:r--,o:--- /var/www/index.php
</code>
définit des permissions dans l'ACL de ''/var/www/index.php'' pour l'utilisateur khadija, le groupe ''site1'' et le reste du monde.

Cette commande permet aussi de modifier les permissions classiques (et remplace dans ce cas ''chmod'') : l'utilisateur, le groupe et le reste du monde initiaux du fichier sont simplement désignés par le préfixe (<code>u:</code>, <code>g:</code>, <code>o:</code>) suivi d'un nom vide : si un fichier ''index.php'' appartient à luce:''www-data'' avec les droits <code>r--r-----</code>, pour donner à l'utilisateur et le groupe les droits en lecture et écriture il suffit d'une commande <code>setfacl -m u::rw,g::rw /var/www/index.php</code>. Si l'utilisateur et le groupe possèdent déjà un droit qui ne serait pas mentionné dans la commande ''setfacl'', ce droit sera annulé. Soit le fichier ''index.php'' avec les droits <code>rw-r-----</code> pour luce:''www-data''. La commande <code>setfacl -m u::r,g::x index.php</code> modifiera les droits à <code>r----x---</code> pour pour luce:''www-data''.

Noter qu'un fichier dont seules les permissions classiques ont été altérées par ''setfacl'' au lieu de ''chmod'' ne reçoit pas pour autant une ACL. De fait, il n'est pas référencé par <code>ls -l</code> comme fichier à ACL (marqueur <code>+</code> ; voir plus bas).

====Droits par défaut et héritage des droits étendus====
Les droits étendus d'un objet parent ne sont pas automatiquement hérités par les objets contenus. Par exemple, si un répertoire (root:''www-data'', <code>rwxr-x-r-x</code>) possède une ACL <code>u:luce:rwx</code>, un fichier créé à l'intérieur (ou déjà présent avant l'adjonction de l'ACL) ne reçoit pas cette ACL et ses droits sont ceux impliqués par l'<i>[[fstab|umask]]</i> défini.

On peut modifier ce comportement en ajoutant, '''aux répertoires seulement''', un attribut ''default'', codé <code>d:</code>, qui se transmet à tous les fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, <code>setfacl -m d:u:luce:rwX /var/www</code> donne à luce les droits de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous ''/var/www'' à partir de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.

====Retirer des permissions====
Pour annuler tout ou partie d'une ACL :
<code>setfacl -b /var/www/index.php
</code>
ôte tout le contenu de l'ACL du fichier, tandis que
<code>setfacl -x u:khadija,g:site1 /var/www/index.php
</code>
retire les permissions propres à khadija et au groupe ''site1''.

Les permissions ACL par défaut d'un répertoire (<code>d:</code>) s'annulent par <code>setfacl -k</code>.

====Le masque====
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
<code>chown luce:www-data index.php
chmod 640 index.php
ls -l index.php
-rw-r----- 1 luce www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
group::r--
other::---</code>
Ce fichier n'a pas d'ACL donc pas de masque.

<code>setfacl -m u:jean:rw,g:web:rw index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---</code>

Maintenant que le fichier possède une ACL, il a reçu un masque : les permissions les plus élevées (utilisateur exclu) étant <code>rw</code>, c'est aussi la valeur du masque.

L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ; on utilise pour cela le préfixe <code>m:</code> suivi du droit maximal à accorder :
<code>getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw-
group::r--
group:web:rw-
mask::rw-
other::---
setfacl -m m:r index.php
getfacl index.php
# file: index.php
# owner: luce
# group: www-data
user::rw-
user:jean:rw- #effective:r--
group::r--
group:web:rw- #effective:r--
mask::r--
other::---</code>

Les valeurs modifiées sont indiquées par le commentaire « ''effective:'' » suivi des permissions effectives après l'application du masque (ici, jean et ''web'' n'ont plus que le droit <code>r</code>, la situation reste la même pour ''www-data'').

<cadre type="note">L'existence même d'un masque renvoie au fonctionnement profond des ACL. Pour en comprendre l'utilité réelle sans se limiter à l'application pragmatique qui en est donnée ici, on se reportera à ''[http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]''.</cadre>

===getfacl===
Cette commande suivie d'un nom de fichier affiche l'ACL de ce fichier (''get file's ACL'' « récupérer l'ACL du fichier »). Par exemple :
<code>getfacl /var/www
# file: var/www
# owner: root
# group: www-data
user::rwx
user:luce:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:khadija:rwx
default:group::rwx
default:group:www-data:r-x
default:mask::rwx
default:other::r-x
</code>

On voit qu'outre les droits traditionnels attribués à root:''www-data'' (droits indiqués après <code>user::</code> et <code>group::</code>), sont aussi définis :
* des droits complets pour luce (<code>user:luce:rwx</code>) ;
* une permission ACL par défaut donnant des droits complets à khadija sur tous les nouveaux fichiers créés sous ''/var/www/'' (<code>default:user:khadija:rwx</code>) ;
* une autre permission ACL par défaut donnant des droits de lecture et d'exécution au groupe ''www-data'' sur les mêmes fichiers (<code>default:group:www-data:r-x</code>).

Noter que <code>user::</code>, <code>group::</code> et <code>other::</code> représentent le triplet ''utilisateur'' / ''groupe'' / ''reste du monde'' des permissions classiques. Appliquer cette commande sur un fichier qui n'a pas d'ACL définie donne les mêmes informations que <code>ls -l</code>, dans un format différent :
<code>setfacl -b index.php # retirer les ACL pouvant exister
ls -l index.php
-rw-r----- 1 root www-data 5055 2005-10-16 18:53 index.php
getfacl index.php
# file: index.php
# owner: root
# group: www-data
user::rw-
group::r--
other::---
</code>

===''ls'', ''cp'' et ''mv''===
Ces commandes doivent pouvoir lister, copier et déplacer les ACL en même temps que les fichiers. Pour les deux premières commande, il faut préciser explicitment que l'on veut afficher/conserver les droits (ce qui est aussi le cas quand on ne travaille que sur les droits classiques) : <code>ls -l</code>, <code>cp -a</code>. La commande ''mv'', quant à elle, préserve toujours les droits.

Quand les droits étendus ne peuvent être conservés (déplacement ou copie vers un système de fichier qui n'est pas configuré pour les recevoir ou utilisation d'une version de ''cp'' trop ancienne), un message d'avertissement en informe l'utilisateur. Par exemple :
<code>setfacl -m u:luce:rw index.php
cp -a index.php /mnt/vfat
cp: preserving permissions for `/mnt/vfat/index.php': Opération non supportée</code>

Noter qu'un fichier comportant une ACL qu'on veut lister par <code>ls -l</code> n'affiche qu'un <code>+</code> à la suite de ses permissions. Seule la commande ''getfacl'', pour l'instant, permet d'avoir connaissance du détail. Par exemple :
<code>setfacl -m u:khadija:rw /var/www/index.php
ls -l /var/www/index.php
-rw-rw----+ 1 khadija www-data 5055 2005-10-16 18:53 /var/www/index.php
</code>
Avec <code>-rw-rw----+</code>, on sait que le fichier possède une ACL (<code>+</code>), sans en connaître les constituants.

===Sauvegarde des données===
Sauvegarder des données dotées d'ACL nécessite :
* l'utilisation d'un système de fichier de stockage compatible ;
* et l'utilisation d'un logiciel de sauvegarde compatible.
:À titre indicatif, ''tar'' et ''cpio'' et ''rsync'' ne le sont pas (à moins d'être patchés), ''star'' et ''pax'' le sont.

Pour contourner le problème de sauvegarde, il est possible d'écrire toutes les ACL dans un fichier qui servira de base à une restauration ultérieure : <code>getfacl -R /dossier/dossier/ > fichier</code> récupère les informations récursivement et les inscrit dans un simple fichier. La restauration se fait au moyen de <code>setfacl --restore=fichier</code>. Il faut, pour qu'elle fonctionne, se placer à la racine contenant l'arborescence, en raison de la notation relative des chemins (d'où le message <code>Removing leading '/' from absolute path names</code> que l'on peut souvent lire en tapant des commandes avec ces programmes). Le chemin d'un répertoire ''/tmp/test'' est enregistré comme ''tmp/test'' : on doit donc, pour restaurer, lancer la commande depuis la racine de ''/tmp'', c'est-à-dire ''/''.

Par exemple : le répertoire ''/tmp/test'' contient trois fichiers à ACL. On sauvegarde les ACL avec <code>getfacl -R /tmp/test > acl.acl</code>. Pour restaurer, on se place à la racine (<code>cd /</code>) et on lance <code>setfacl --restore=acl.acl</code>. Si on avait lancé la commande depuis ''/test'', ''setfacl'' aurait renvoyé les erreurs :
<code>
setfacl: tmp/test: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/a: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/b: Aucun fichier ou répertoire de ce type
setfacl: tmp/test/c: Aucun fichier ou répertoire de ce type</code>

==Notes concernant la syntaxe de ''setfacl''==
Les préfixes abrégés peuvent être développés et les permissions codées en octal (avec préfixe ''0'' optionnel). Ces trois commandes ont donc le même sens :
<code>setfacl -m d:u:luce:rw,g:www-data:r,o:- index.php
setfacl -m default:user:luce:6,group:www-data:4,other:0 index.php
setfacl -m default:user:luce:06,group:www-data:04,other:00 index.php</code>

----
<cadre type="note">
Tout au long de ce document, on a parlé de « permissions classiques » opposées à des « permissions étendues » qui leur seraient ajoutées. C'est une simplification : dans les faits, un système de fichiers monté avec le support des ACL change son appréhension globale des permissions, qui sont toutes des ACL, qu'elles soient minimales (utilisateur primaire, groupe primaire, reste du monde) ou étendues. Dans ce dernier cas, c'est la notion de groupe qui est redéfinie : tout utilisateur ou groupe ajouté à l'utilisateur primaire est enregistré avec ses droits dans une classe « groupe » étendue.

Cela explique la nécessité d'un masque : c'est la valeur limite réelle de la classe « groupe », que les entrées qu'elle contient ne peuvent dépasser. Un <code>ls -l</code> sur un fichier dont le masque ACL a été abaissé à <code>r--</code> alors que les droits du groupe primaire étaient auparavant <code>rw-</code> donnera : <code>-rw-r-----+</code> et non <code>-rw-rw----+</code>. Inversement, si l'on change par ''chmod'' les permissions du groupe principal, cela revient à changer le masque, donc les permissions de tous les utilisateurs et groupes ajoutés.
</cadre>

==Documents annexes==
* '''Articles de Léa : '''
** les [[permissions]] « classiques » POSIX.1 ;
** les [[attributs étendus]] des systèmes de fichier ''ext2'' et ''ext3'' ;
* '''pages de manuel : '''
** <code>man acl</code> ;
** <code>man setfacl</code> ;
** <code>man getfacl</code>.
* '''sites externes : '''
** [http://www.linuxplusvalue.be/mylpv.php?id=153 Les ACL POSIX] ;
** [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux].

{{Copy|27.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-27T01:40:57Z

Vincent Ramos : /* Commande */

Attributs étendus

2005-10-27T01:38:06Z

Vincent Ramos :

Attributs étendus

2005-10-27T01:37:42Z

Vincent Ramos : Suite

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="warning">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre.</cadre>

Les [[système de fichiers|systèmes de fichiers]] ''ext2'' et ''ext3'' (ainsi que ''reiserfs'' dans certaines conditions) offrent la possibilité de donner à des fichiers (fichiers réels ou répertoires) des '''attributs étendus''' qui s'ajoutent aux [[permissions|permissions classiques POSIX.1]], éventuellement complétées par les [[ACL|permissions étendues ACL]].

<cadre type="warning">Seuls ces systèmes de fichiers offrant ces attributs, il n'est pas prudent ─ en terme de sécurité ─ de s'appuyer lourdement sur leur présence si l'on est amené à transférer fréquemment des données d'un système de fichiers ''ext'' à un autre. D'autre part, il convient de tester ces possibilités : toutes les versions du noyau n'en tiennent pas compte de la même manière.</cadre>

==Mise en place==
Il n'y a rien à faire pour des partitions en ''ext2'' ou ''ext3'', qui respectent nativement les attributs étendus.

Chose assez peu connue, cependant, le système de fichiers ''reiserfs'' peut respecter les attributs étendus, à condition d'[[fstab|être monté]] avec l'option idoine <code>attrs</code>. Pour ce faire, les commandes suivantes sont appliquées :
* sur une partition non encore montée : <code>mount -t reiserfs -o attrs /dev/partition /point/de/montage</code> ;
* sur une partition déjà montée : <code>mount -o attrs /point/de/montage</code> (remontage à la volée).

Pour que la prise en compte soit effective à chaque montage automatique (le cas échéant), il faut ajouter l'option dans ''[[fstab|/etc/fstab]]''. Par exemple :
<code>
/dev/hda1 / reiserfs defaults,acl,attrs 0 1
</code>

Enfin, on peut recompiler son noyau avec l'option <code>CONFIG_REISERFS_FS_XATTR = y</code> pour que le mode <code>attr</code> soit automatiquement appliqué lors du montage d'une partition en ''reiserfs''.

<cadre type="warning">Noter que des fichiers d'une partition en ''reiserfs'' montée sans l'option <code>attrs</code> (ou la recompilation du noyau) peuvent recevoir des attributs étendus : ils seront bien enregistrés mais n'auront aucun effet. La commande de modification d'attributs, ''chattr'', ne renverra donc aucun message d'erreur sans pour autant que les attributs soient pris en compte. Ce détail peut avoir des répercussion pour la sécurité du système : on peut, à tort, croire protéger des fichiers.</cadre>

==Types d'attributs==
Selon la norme POSIX.1, tout fichier possède les permissions en lecture, écriture et exécution. On peut leur adjoindre des attributs supplémentaires, qui s'imposent à tous les utilisateurs hormis root quand ils modifient les actions qu'on peut avoir sur eux. Certains attributs sont actuellement expérimentaux (octobre 2005) et nécessitent de patcher le noyau pour qu'ils aient un effet réel.

;append only (a), « ajouter seulement » ─ '''réservé à root'''
:Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.
;compressed (c), « compresser » ─ '''expérimental'''
:Le fichier est automatiquement compressé ─ si c'est utile, et avec un format de compression le plus efficace ─ quand il est stocké. La décompression lors de la lecture et la compression des données ajoutées au fichier par la suite se font à la volée, de manière transparente pour l'utilisateur (la commande <code>ls -l</code>, par exemple, montre la taille décompressée).
:Cet attribut appliqué à un répertoire ne le compresse pas mais fait se compresser automatiquement tout nouveau fichier qu'on y crée.
;no dump (d), « pas de sauvegarde »
:Un fichier ainsi marqué sera ignoré par la commande ''dump''.
;immutable (i), « immuable » ─ '''réservé à root'''
:Protège le fichier contre toute modification (suppression, modification, déplacement, changements de permissions), même par root, et empêche qu'on crée un lien vers lui. Seule la modification des attributs étendus est permise à son propriétaire et seul root peut enlever l'attribut « immuable » d'un fichier.
:Cet attribut est sans doute l'un des plus intéressants.
;data journalling (j), « journalisation des données » ─ '''réservé à root'''
:Cet attribut n'est utile qu'avec une partition en ''ext3'' montée avec les options de journalisation des données <code>data=ordered</code> (montage par défaut) ou <code>data=writeback</code> pour simuler une journalisation du type <code>data=journal</code>, où les données sont écrites dans le journal avant de l'être dans le fichier lui-même. Consulter <code>man mount 8</code> pour plus de détails sur les mécanismes de journalisation d'''ext3''.
:Sur une partition ''ext3'' en mode <code>data=journal</code>, cet attribut est ignoré, de même que sur les partitions en ''ext2'' et ''reiserfs'', le premier type n'étant pas journalisé, le second l'étant d'une manière incompatible.
;secure deletion (s), « effacement sécurisé » ─ '''expérimental'''
:
;no tail-merging (t)
;undeletable (u) ─ '''experimental'''
;no atime updates (A)
;synchronous directory updates (D)
;synchronous updates (S)
;top of directory hierarchy (T).

==Commande==
lschattr, chattr
e2fsprogs
<!-- The ‘c’, ’s’, and ‘u’ attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels. These attributes may be implemented in future versions ext2 and ext3. The ‘j’ option is only useful if the filesystem is mounted as ext3. The ‘D’ option is only useful on Linux kernel 2.5.19 and later.

{{Copy|28.10.05|Vincent Ramos|FDL}}

Attributs étendus

2005-10-26T23:41:58Z

Vincent Ramos : Début

Les permissions sur les fichiers

2005-10-26T23:32:56Z

Vincent Ramos : /* Attributs étendus */ lien

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser/modifier les permissions ==

=== Ligne de commande ===

En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x   18 username     users        2048 jan  7 19:22 . <br /> drwxr-xr-x    7 root     root         1024 fév  6  1996 .. <br /> -rw-------    1 username     users         147 jan  7 19:22 .Xauthority <br /> -rw-r--r--    1 username     users        1899 jui 28 21:01 .Xdefaults <br /> -rw-------    1 username     users        5860 jan  7 19:22 .bash_history <br /> -rw-r--r--    1 username     users          24 jui 28 21:01 .bash_logout <br /> -rw-r--r--    1 username     users         262 jui 29 18:15 .bash_profile <br /> -rw-r--r--    1 username     users         434 jui 28 21:01 .bashrc <br /> -rw-r--r--    1 username     users        2626 jui 28 21:01 .emacs <br /> -rw-r--r--    1 username     users         532 jui 28 21:01 .inputrc <br /> drwxr-xr-x    3 username     users        1024 jui 28 21:01 .kde <br /> -rw-r--r--    1 username     users        1546 jan  7 19:04 .kderc <br /> -rwxr-xr-x    1 username     users        1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code><font size="+1">rwx</font></code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'''<font size="+1">rwx</font>'''r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'''<font size="+1">r-x</font>'''r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code><font size="-1">drwxr-xr-x 18 username users   2048 jan 7 19:22 .</font></code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code><font size="-1">-rw-r-----   1 username wwwadm 1728 jan 7 19:22 projet-www</font></code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modification ==

=== Les droits : <code>chmod</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> le paramétre '-R' permet de rendre récursive l'application de la nouvelle propriété (i.e. répertoires et sous-répertoires).

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [../dev/suid_scripts.php3 SUID Scripts] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Les permissions sur les fichiers

2005-10-26T23:32:33Z

Vincent Ramos : /* ACL */ ortho

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser/modifier les permissions ==

=== Ligne de commande ===

En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x   18 username     users        2048 jan  7 19:22 . <br /> drwxr-xr-x    7 root     root         1024 fév  6  1996 .. <br /> -rw-------    1 username     users         147 jan  7 19:22 .Xauthority <br /> -rw-r--r--    1 username     users        1899 jui 28 21:01 .Xdefaults <br /> -rw-------    1 username     users        5860 jan  7 19:22 .bash_history <br /> -rw-r--r--    1 username     users          24 jui 28 21:01 .bash_logout <br /> -rw-r--r--    1 username     users         262 jui 29 18:15 .bash_profile <br /> -rw-r--r--    1 username     users         434 jui 28 21:01 .bashrc <br /> -rw-r--r--    1 username     users        2626 jui 28 21:01 .emacs <br /> -rw-r--r--    1 username     users         532 jui 28 21:01 .inputrc <br /> drwxr-xr-x    3 username     users        1024 jui 28 21:01 .kde <br /> -rw-r--r--    1 username     users        1546 jan  7 19:04 .kderc <br /> -rwxr-xr-x    1 username     users        1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code><font size="+1">rwx</font></code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'''<font size="+1">rwx</font>'''r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'''<font size="+1">r-x</font>'''r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code><font size="-1">drwxr-xr-x 18 username users   2048 jan 7 19:22 .</font></code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code><font size="-1">-rw-r-----   1 username wwwadm 1728 jan 7 19:22 projet-www</font></code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modification ==

=== Les droits : <code>chmod</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> le paramétre '-R' permet de rendre récursive l'application de la nouvelle propriété (i.e. répertoires et sous-répertoires).

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [../dev/suid_scripts.php3 SUID Scripts] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[fstab|systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Aide:Aide

2005-10-26T23:24:40Z

Vincent Ramos : /* Aide à propos du wiki */ retouches

= Aide à propos de Linux et des logiciels libres =
* Vous voulez [[Intro-index|découvrir Linux et/ou les logiciels libre]].
* Vous êtes débutants et un peu perdu, vous ne savez pas comment vous y retrouver. Consultez [[Intro-aide|cette introduction]].
* Vous avez une question précise à poser. Utilisez les [http://lea-linux.org/pho/ forums de Léa]. Ils sont là pour cela. Attention à bien poster votre question sur le bon forum.
= Aide à propos du [[wiki]] =
* [http://meta.wikimedia.org/wiki/Aide:Édition Comment éditer une page dans médiawiki]
* Comment mettre en forme de telle ou telle façon ? Consulter la documentation sur la [http://meta.wikimedia.org/wiki/Aide:Syntaxe_wiki syntaxe wiki] et les [[Aide:Comment_éditer_une_page|spécificités du logiciel Mediawiki installé sur Léa]]

Lea Linux:C'est quoi un wiki ?

2005-10-26T23:24:03Z

Vincent Ramos : /* Et Léa dans tout cela ? */ typo

= Étymologie =
Le nom ''wiki'' vient du terme hawaiien ''wiki wiki'', qui signifie « rapide » ou « informel ».

= Sens informatique =
Un wiki est un site collaboratif facilement modifiable par tout le monde : n'importe qui peut y ajouter un document, un paragraphe ou modifier le contenu d'une page. Consulter ''[http://meta.wikimedia.org/wiki/Aide:Édition Comment éditer une page dans médiawiki]'' et ''[http://meta.wikimedia.org/wiki/Aide:Syntaxe_wiki Syntaxe wiki]'' pour plus de détails.

Léa restreint quelque peu cette définition en établissant un système de modération a priori.

= Et ça marche ? =
Il faut croire, vu le succès par exemple de [http://fr.wikipedia.org Wikipédia] mais aussi de plusieurs sites de documentation (la documentation de Gentoo est par exemple écrite sur un wiki).

= Et c'est pas un peu la chienlit ? =
La qualité d'un wiki est directement liée à la quantité de relecteurs rapportée au nombre d'éditeurs. Si beaucoup de monde édite n'importe comment mais que personne ne relit ce qui est publié, ça ne fonctionne pas. Un site comme Wikipédia, qui a beaucoup de relecteurs, fonctionne assez bien : les acte de vandalisme y sont le plus souvent repérés rapidement et éliminés. Des participants auxquels la communauté des participants réguliers accorde son crédit, sont même dotés d'outils leur permettant de corriger rapidement les bévues.

= Et Léa dans tout cela ? =
Sur Léa, nous ne sommes pas encore capable d'assurer un tel niveau de relecture. Nous avons donc décidé, pour ne trop prendre le risque de voir se produire n'importe quoi, de modérer notre wiki. Les puristes de Wikipédia diront que Léa n'est donc pas un wiki : ils n'auront pas totalement tort. Néanmoins, il restera facile d'éditer un article, d'en ajouter un... Seulement, pour s'afficher correctement, les modifications devront être validées, et les nouvelles pages acceptées par les modérateurs de Léa.

=Quelles sont les autres différences entre Léa et un wiki « classique » ?=
Cette question trouve sa réponse dans l'article ''[[Aide:Comment_éditer_une_page|Spécificités du médiawiki installé sur Léa]]''.

Lea Linux:C'est quoi un wiki ?

2005-10-26T23:23:38Z

Vincent Ramos : Ajout de liens vers de l'aide (il faut établir le plus de ponts possibles)

= Étymologie =
Le nom ''wiki'' vient du terme hawaiien ''wiki wiki'', qui signifie « rapide » ou « informel ».

= Sens informatique =
Un wiki est un site collaboratif facilement modifiable par tout le monde : n'importe qui peut y ajouter un document, un paragraphe ou modifier le contenu d'une page. Consulter ''[http://meta.wikimedia.org/wiki/Aide:Édition Comment éditer une page dans médiawiki]'' et ''[http://meta.wikimedia.org/wiki/Aide:Syntaxe_wiki Syntaxe wiki]'' pour plus de détails.

Léa restreint quelque peu cette définition en établissant un système de modération a priori.

= Et ça marche ? =
Il faut croire, vu le succès par exemple de [http://fr.wikipedia.org Wikipédia] mais aussi de plusieurs sites de documentation (la documentation de Gentoo est par exemple écrite sur un wiki).

= Et c'est pas un peu la chienlit ? =
La qualité d'un wiki est directement liée à la quantité de relecteurs rapportée au nombre d'éditeurs. Si beaucoup de monde édite n'importe comment mais que personne ne relit ce qui est publié, ça ne fonctionne pas. Un site comme Wikipédia, qui a beaucoup de relecteurs, fonctionne assez bien : les acte de vandalisme y sont le plus souvent repérés rapidement et éliminés. Des participants auxquels la communauté des participants réguliers accorde son crédit, sont même dotés d'outils leur permettant de corriger rapidement les bévues.

= Et Léa dans tout cela ? =
Sur Léa, nous ne sommes pas encore capable d'assurer un tel niveau de relecture. Nous avons donc décidé, pour ne trop prendre le risque de voir se produire n'importe quoi, de modérer notre wiki. Les puristes de Wikipédia diront que Léa n'est donc pas un wiki() : ils n'auront pas totalement tort. Néanmoins, il restera facile d'éditer un article, d'en ajouter un... Seulement, pour s'afficher correctement, les modifications devront être validées, et les nouvelles pages acceptées par les modérateurs de Léa.

=Quelles sont les autres différences entre Léa et un wiki « classique » ?=
Cette question trouve sa réponse dans l'article ''[[Aide:Comment_éditer_une_page|Spécificités du médiawiki installé sur Léa]]''.

Aide:Aide

2005-10-26T23:20:59Z

Vincent Ramos : /* Aide à propos du wiki */ lien

= Aide à propos de Linux et des logiciels libres =
* Vous voulez [[Intro-index|découvrir Linux et/ou les logiciels libre]].
* Vous êtes débutants et un peu perdu, vous ne savez pas comment vous y retrouver. Consultez [[Intro-aide|cette introduction]].
* Vous avez une question précise à poser. Utilisez les [http://lea-linux.org/pho/ forums de Léa]. Ils sont là pour cela. Attention à bien poster votre question sur le bon forum.
= Aide à propos du [[wiki]] =
* [http://meta.wikimedia.org/wiki/Aide:Édition Comment éditer une page dans médiawiki]
* Comment mettre en forme de telle ou telle façon ? Consulter la documentation la [http://meta.wikimedia.org/wiki/Aide:Syntaxe_wiki syntaxe WIKI] et les [[Aide:Comment_éditer_une_page|spécificités du médiawiki installé sur Léa]]