Mais pour le coup, ton problème est plus lié au comportement de Virtualbox qu’aux acl.

Et enfin utilise plutot inotify que dnotify :-)

Et justement, un chmod impacte les acl puisqu’il modifie le mask.

Toujours faire attention au mask, c’est la source de beaucoup de problèmes et d’incompréhensions.

$ find /vm/VirtualBox/ -type d -exec setfacl -m g:vboxusers:rwx,m::rwx,d:u::rwx,d:g::rwx,d:g:vboxusers:rwx,d:m::rwx {} \;
$ find /vm/VirtualBox/ -type f -exec setfacl -m u::rw,g::rw,g:vboxusers:rw,m::rw {} \;

Je précise tout de suite que les répertoires .VirtualBox des utilisateurs pointent tous sur /vm/VirtualBox/. Après cette opération on a bien ce qu’il faut, enfin a priori :

$ getfacl /vm/VirtualBox/Machines
getfacl: Removing leading ‘/’ from absolute path names

1. file: vm/VirtualBox/Machines
2. owner: tom
3. group: grouptom

user::rwx
group::rwx
group:vboxusers:rwx
mask::rwx
other::—
default:user::rwx
default:group::rwx
default:group:vboxusers:rwx
default:mask::rwx
default:other::—

Quand je crée une nouvelle VM, ici « test », j’obtiens un mauvais masque sur les fichiers créés mais pas sur les répertoires :

$ getfacl /vm/VirtualBox/Machines/test/test.xml
getfacl: Removing leading ‘/’ from absolute path names

1. file: vm/VirtualBox/Machines/test/test.xml
2. owner: alfred
3. group: groupalfred

user::rw-
group::rwx #effective:—
group:vboxusers:rwx #effective:—
mask::—
other::—

$ getfacl /vm/VirtualBox/Machines/test/
getfacl: Removing leading ‘/’ from absolute path names

1. file: vm/VirtualBox/Machines/test/
2. owner: alfred
3. group: groupalfred

user::rwx
group::rwx
group:vboxusers:rwx
mask::rwx
other::—
default:user::rwx
default:group::rwx
default:group:vboxusers:rwx
default:mask::rwx
default:other::—

Ce qui est étrange c’est que ça ne le fait pas sur tous les fichiers VirtualBox. Ça le fait sur les fichiers d’image disque *.vdi et *.sav mais pas sur le fichier de configuration principal VirtualBox.xml… Ce serait l’application VirtualBox qui remettrait à zéro le masque de certains fichiers ? Quelle drôle d’idée…

Cela force le mask des fils créés à — ce qui produit des effective à —

Par contre pour la modification des droits c’est bizarre, avec quoi édite-tu le fichier ?

Tout ceci est très intéressant et j’ai donc foncé pour mettre en pratique. Malheureusement j’ai un problème qui a l’air de venir du masque que je ne maîtrise pas du tout… J’essaie de partager un fichier en lecture/écriture pour 2 utilisateurs tom et alfred de groupe principal différent mais appartenant à un même groupe secondaire, disons alftom. Si tom écrit un fichier et modifie les ACL avec cette commande :

$ setfacl -m g:alftom:rw <fichier>

alors alfred ne peut toujours pas lire le fichier et getfacl rapporte pour le groupe alftom un message du type :

group:alftom:rw- #effective:—

Pour arranger les choses, j’ai modifié le masque avec :

$ setfacl -m m::rw <fichier>

À ce moment-là alfred peut ouvrir et modifier le fichier, ce qu’il fait et ça va changer les UID et GID du fichier, normal. Par contre les ACL sont alors visiblement modifiées aussi au niveau du masque, puisque tom ne peut plus lire le fichier. La commande getfacl rapporte que le groupe alftom a toujours les droits de lecture/écriture mais apparaît à nouveau le message « group:alftom:rw- #effective:— ».

Quel est donc le mystère de ce masque ? C’est le sujet du 3ème billet sur le sujet ? ;-)

Les default peuvent te permettre de les interdire aux nouveaux "par défaut", pas mieux qu’un umask. Rien n’empêche un utilisateur de faire un chmod ou un setfacl.