Les ACL étendues ne sont pas toujours héritées

J'ai une application qui génère des files de rapport dans /opt/reports avec des files appartenant root: root à 0600. Dans une tentative pour permettre à un système externe de traiter automatiquement ces rapports, j'ai créé un nouvel user de count de service avec le groupe 'report'. groupe pour /opt/reports pour signaler et définir le bit SUIG, puis définir l'ACL par défaut sur le directory /opt/reports pour inclure le groupe de rapport avec 400 et masquer avec 400.

Je remarque que lorsque je crée manuellement un file, les permissions sont toutes définies comme prévu, mais lorsque l'application crée un file, les valeurs par défaut ne sont pas héritées.

 [root@reports1 ~]# getfacl /opt/reports getfacl: Removing leading '/' from absolute path names # file: opt/reports # owner: root # group: report user::rwx group::rx other::rx [root@reports1 ~]# setfacl -R -d -n -mg:report:r,m::r /opt/reports/ [root@reports1 ~]# getfacl /opt/reports getfacl: Removing leading '/' from absolute path names # file: opt/reports # owner: root # group: report user::rwx group::rx other::rx default:user::rwx default:group::rx #effective:r-- default:group:report:r-- default:mask::r-- default:other::rx 

La création du file manuellement semble fonctionner correctement

 [root@reports1 ~]# echo "This is a test file" > /opt/reports/testfile.txt [root@reports1 ~]# ls -l /opt/nessus_reports/testfile.txt -rw-r--r--+ 1 root report 20 Apr 24 11:16 /opt/reports/testfile.txt [root@reports1 ~]# getfacl /opt/reports/testfile.txt getfacl: Removing leading '/' from absolute path names # file: opt/reports/testfile.txt # owner: root # group: report user::rw- group::rx #effective:r-- group:report:r-- mask::r-- other::r-- 

Lors de la génération d'un rapport avec l'application, cependant, le masque se propage vers le nouveau file

 [root@reports1 ~]# ls -l /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d -rw-------+ 1 root report 125952 Apr 24 11:18 /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d [root@reports1 ~]# getfacl /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d getfacl: Removing leading '/' from absolute path names # file: opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d # owner: root # group: report user::rw- group::rx #effective:--- group:report:r-- #effective:--- mask::--- other::--- 

Est-ce ce comportement attendu, et je comprend simplement la terminologie impliquée? Est-ce que j'ai manqué un drapeau ou une option quelque part, est-ce que je l'approche de la mauvaise direction entièrement?

[Tout d'abord, il semble que votre bit SUIG soit perdu (je m'attends à un "flags: -s-" dans la sortie getfacl). Cependant, ce n'est pas ce qui cause le problème ici.]

Il semble que le générateur de rapports crée non seulement le file avec un 027 umask, mais aussi un chmod explicite () sur le file. Lorsque cela se produit, le masque POSIX ACL est perdu.

Essayez les éléments suivants (en tant que root):

 touch /opt/reports/testfile.txt getfacl /opt/reports/testfile.txt chmod 640 /opt/reports/testfile.txt getfacl /opt/reports/testfile.txt 

Il semble que l'explicite chmod () gâte les choses.

C'est le comportement par défaut, car les files créés ont l'association user: groupe de l'user qui les crée. Il y a encore de l'espoir. Il vous suffit de vous assurer que lorsque l'application est exécutée, elle est exécutée par un user qui a le groupe de rapport comme groupe principal. Il existe de nombreux exemples de la façon de faire cela. Si vous regardez certains des scripts dans /etc/init.d, presque tous le font lors du démarrage d'un service. Bonne chance! (Sur une note secondaire, il montre que vous êtes un administrateur Windows, car toutes les permissions héritées sur les objects enfants sont par défaut les permissions de style Windows, le changement mental vers les files de style Unix sur les files peut être un peu délicat.)