Bonjour Rx44
Merci pour la confirmation et le commentaire: bien que pour moi il s’agisse d’un usage familial, votre scénario est exactement celui auquel je pensais en me souvenant d’une vie antérieure: un utilisateur ou un groupe supplémentaire, et une permission à o:— imposent que les ACL fonctionnent correctement. Avec nos Debian/Ubuntu, si en plus on veut une utilisation transparente pour les utilisateurs, il faut aussi que l’héritage des permissions soit automatique (ou au moins puisse l’être), ou alors il faut qu’un informaticien mette les mains dans le cambouis.
J’ai fini par trouver un site qui semble confirmer que ce problème existe bien, mais c’est un bug déclaré en anglais dans le paquet coreutils et je n’y vois pas de trace d’activité depuis sa déclaration en 2011! C’est vraiment curieux que ça ne pose pas plus de problèmes que ça, on ne trouve ailleurs aucun site qui indique que les ACL ne s’héritent pas correctement, alors que j’ai cru comprendre que ça faisait partie du fonctionnement prévu. Le bug est là: debbugs.gnu.org/cgi/bugreport.cgi?bug=8527. Le reste, sur les forums ubuntu et les wikis, c’est moi qui ai posté en septembre, et encore une fois, rien du tout par des experts sur les forums officiels, pire, les ACL y sont toujours présentées comme fonctionnelles 
.
J’avais aussi pensé à un job cron, mais moi aussi je trouve ça assez peu élégant. Sinon, j’ai aussi eu l’idée d’un truc à base de inotify, car il s’agit, je pense, d’un mécanisme qui doit pouvoir surveiller ~en temps réel~ une arborescence. Je sais qu’il est justement utilisé (mais pour autre chose, je pense pour simplement détecter la présence de nouveaux fichiers et les prendre en compte) dans le logiciel (minidlna) pour lequel je veux, justement donc, mettre en œuvre les ACL, et ça semble se confirmer à la lecture du wiki Debian (chercher inotify): wiki.debian.org/Permissions#Def … ted.29_ACL (la note en haut, c’est encore moi). C’est maigre, mais entre les sources de minidlna et de la doc sur inotify, on doit pouvoir arriver à quelque-chose 
, enfin vu mon niveau, il faudra beaucoup de temps.
Concernant votre remarque sur FTP, j’ai effectivement lu le même genre de remarque au sujet de rsync et de la “non préservation”, mais je trouve (c’est mon point de vue pour le moment) que ça n’est pas le problème: quand on dit “préservation…”, on sous-entend (ou on devrait) “…des permissions de la source”. Si on pensait à celles de la cible, on devrait plutôt dire “contournement des ACL en place sur le dossier parent de la cible”, mais je ne vois pas l’intérêt. De toute façon qu’y aurait-il à préserver comme autorisations quand la source est sur une partition style FAT32.
Donc quand on pense au résultat sur la cible en disant “préservation”, il serait plus clair et direct de dire simplement “respect (sous-entendu, des ACL déjà en place sur le dossier parent de la dite cible)”. Autrement dit, les ACL sont un fonctionnement des permissions impliquant tellement de logique sous-jacente qu’on devrait éviter un maximum de sous-entendus… surtout quand ça ne marche pas comme prévu.
En fait je crois que le umask devrait être ignoré par défaut dès qu’il y a une ACL en jeu sur la cible, et ceci quel que soit le processus ou l’utilisateur, quitte à ce que l’ACL empêche la copie ou le déplacement. Ça doit être impossible dans Linux, sinon les développeurs auraient déjà corrigé ça… je pense.
Merci encore pour votre réponse. Si je trouve quelque-chose, je vous ferai signe ici.
