Per avere a disposizione le ACL posix occorre che il kernel le supporti (ACL ed Extended Attributes) e che il mount sia fatto con supporto per le ACL ed eventualmente Extended Attributes.

In fstab occorre quindi specificare: 

/dev/hdc1       /ud1            ext3    defaults,noatime,acl    0       2

per l'uso delle ACL, e: 

/dev/hdc1       /ud1            ext3    defaults,noatime,acl,user_xattr    0       2

per l'uso delle ACL e degli attributi estesi.

Creazione e gestione delle ACL sul file system

Quando si crea una directory da condividere con Samba usando le ACL, e` importante ricordare che occorre impostarne correttamente i permessi onde evitarsi casini pazzeschi dopo. Tipicamente la directory, se deve essere gestita principalmente da un gruppo puo` essere owned dal gruppo in questione, con il bit SGID settato, e poi le si possono applicare le ACL per gli altri gruppi o utenti, ricordando che oltre alle ACL vanno settate anche le DEFAULT ACL, in modo che quello che viene creato sotto di essa abbia le stesse ACL della directory iniziale.

Per esempio, la directory "amministrazione" che deve venire usata dal gruppo amministrazione ma anche letta dagli acquisti e letta/scritta dalla direzione, io la imposterei cosi`: 

mkdir amministrazione

 # owned dal gruppo amministrazione
chown root.amministrazione amministrazione

 # setgid, user e gruppo hanno rwx, other ha nulla
chmod 2770 amministrazione

 # direzione ha rwx, acquisti ha rx
setfacl -m g:direzione:rwx,g:acquisti:rx amministrazione

 # come sopra, ma setto le default ACL, che verranno ereditate da cio` che viene creato sotto
setfacl -d -m g:direzione:rwx,g:acquisti:rx amministrazione

In questo modo uso le ACL per dare accesso ai gruppi "secondari", lasciando il gruppo principale (amministrazione) impostato nei permessi "standard" di Linux. Ovviamente avrei potuto anche dare ownsership a root.root e inserire tutti i permessi di accesso degli utenti nelle ACL, gruppo principale compreso.

Problema con le ACL e il "move" dei files

Quando si effettua un "move" di files (e alberi di directory) all'interno dello stesso file system, questi tengono le ACL originali anche se le default ACL della directory di destinazione sono diverse. In pratica, muovendo files fra directory con ACL completamente diverse, questi ritengono le ACL che avevano all'inizio, il che e` sbagliato se nella directory di destinazione ci sono delle default ACL che dovrebbero essere ereditate dai files che si trovano sotto di essa. Questo e` un problema di file system e non di Samba (si ottiene lo stesso risultato con un "mv" da shell o un move da un client windows). Tra l'altro, anche se la directory di destinazione e` impostata "setgid", anche il gruppo non viene correttamente settato e resta quello di origine.

L'unica soluzione "facile" e` fare una copia e non un move dei files (da client Windows). Cosi` facendo i files di destinazione sono creati correttamente (setgid e default ACL)

Se si e` fatto un move, e` possibile correggere le acl sul tree di destinazione cosi`: 

cd /path/to/destination_dir
getfacl . | setfacl -R --set-file=- *

Questo comunque non corregge l'ownership, direi.

Impostazioni in smb.conf

Se si vogliono usare le ACL posix su uno share, e` consigliabile impostare la mappatura degli attributi DOS su attributi estesi del file system e non sull'attributo X di user,group e other, questo perche` altrimenti si creano casini molesti fra le mask delle acl e quella standard dei permessi del file system. In proposito, vedi ../AttributiEstesiDos. Inoltre tipicamente si vorranno usare delle ACL di defualt ed ereditarle all'interno dell'albero di directory. Una imposazione di base per uno share con le ACL potrebbe essere la seguente: 

map archive = no
map system = no
map hidden = no
store dos attributes = yes 
inherit permissions = yes
inherit acls = yes          {le dir sotto ereditano le ACL di default da sopra (leggi man smb.conf!)}

Tutto questo pero` va provato per vedere se ci sono aggiustamenti da fare, ovvero se in qualche situazione (tipo un utente che mette un file read-only da windows) ci sono effetti collaterali. Per essere precisi, andrebbero provate e verificate le impostazioni di mask e force che uso negli share senza ACL per vedere se e quali si applicano a quelli con le ACL.

Docuemntazione varia

Backup e restore delle ACL

Quasi nessun sistema di backup supporte le ACL. Tar e afio (quindi tob) ad esempio non le supportano. Al momento le due soluzioni possibili sono:

Questo e` un esempio (imperfetto) di comando di backup e verify con star: 

star cvzf /mnt/ud1_dati.star.gz -acl -xattr -artype=exustar --block-number  /ud1/dati/ > /mnt/star.log
star -diff -xattr -/ -z -f /mnt/ud1_dati.star.gz

Questo e` un esempio di restore con tutti gli attributi e le ACL: 

star xzpf test2.star.gz  -xattr -acl  -C <directory di output>

Restore di un singolo file salvandolo nella directory "dir_recover" anziche` nella sua directory originale (notare gli apici e il fatto che manca lo slash all'inizio del nome del file da recuperare): 

star zxpf test2.star.gz -xattr -acl -C dir_recover 'ud1/test3/acquisti/file.xls'

Restore di files che matchano un pattern, salvandoli nella dir corrente. Questo restora i files che contengono "ECO" nel nome. (lo slash viene strippato quindi non vai a sovrascrivere nulla a meno che non li restori in /): 

star zxpf test2.star.gz -xattr -acl pattern='*ECO*'

Nota importante

Le acl su ext3 ed ext2 hanno sofferto di un baco che provoca la perdita delle default ACL su una directory in determinati casi, ben poco ripetibili. il problema dovrebbe essere risolto a partire dalla patch versione 0.8.72. 

>    I  have  read   the  old  messages  about  the issue where default ACLs
>    sometimes  disappear from folders using ext3, but I have not understood
>    if  this  issue  has  been completely solved or not, and in which patch
>    version.

This was fixed in version 0.8.72. The bug was in function ext2_xattr_cmp and
ext3_xattr_cmp: They did not compare the e_name_index field.

I kernel debian fino a 2.4.27-10 e fino a 2.6.8-16 (alla data del 8/8/2005 non ci sono ancora le fix, che immagino andranno nelle versioni 11 e 17 rispettivamente) sono bacati. Le versioni successive dovrebbero avere il baco messo a posto. Sicuramente e` a posto il kernel 2.6.12 debian. Per il momento, comunque, qui c'e` la patch: 

--- fs/ext2/xattr.c     2005-08-09 17:59:44.000000000 +0900
+++ fs/ext2/xattr.c     2005-08-09 17:59:46.000000000 +0900
@@ -977,6 +977,7 @@
                if (IS_LAST_ENTRY(entry2))
                        return 1;
                if (entry1->e_hash != entry2->e_hash ||
+                   entry1->e_name_index != entry2->e_name_index ||
                    entry1->e_name_len != entry2->e_name_len ||
                    entry1->e_value_size != entry2->e_value_size ||
                    memcmp(entry1->e_name, entry2->e_name, entry1->e_name_len))
--- fs/ext3/xattr.c     2005-08-09 17:58:31.000000000 +0900
+++ fs/ext3/xattr.c     2005-08-09 17:58:50.000000000 +0900
@@ -1025,6 +1025,7 @@
                if (IS_LAST_ENTRY(entry2))
                        return 1;
                if (entry1->e_hash != entry2->e_hash ||
+                   entry1->e_name_index != entry2->e_name_index ||
                    entry1->e_name_len != entry2->e_name_len ||
                    entry1->e_value_size != entry2->e_value_size ||
                    memcmp(entry1->e_name, entry2->e_name, entry1->e_name_len))

La patch si puo` anche scaricare qui: xattr-sharing.patch e si applica con "patch -p0"

Samba/AccessControlLists (last edited 2011-06-01 14:16:22 by Kurgan)