ACLs estendidas nem sempre estão sendo herdadas

Question

Eu tenho um aplicativo que gera arquivos de relatório em /opt/reports com arquivos de propriedade root: root em 0600. Na tentativa de permitir que um sistema externo processe automaticamente esses relatórios, criei um novo usuário de conta de serviço com o grupo 'report' alterou o grupo para /opt/reports para informar e definir o bit SUIG e, em seguida, definir a ACL padrão no diretório /opt/reports para incluir o grupo de relatórios com 400 e a máscara com 400.

Percebo que quando eu crio manualmente um arquivo, as permissões são definidas como esperado, no entanto, quando o aplicativo cria um arquivo, os padrões não são herdados.

[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x

[root@reports1 ~]# setfacl -R -d -n -m g: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::r-x
other::r-x
default:user::rwx
default:group::r-x              #effective:r--
default:group:report:r--
default:mask::r--
default:other::r-x

Criar o arquivo manualmente parece funcionar ok

[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::r-x                      #effective:r--
group:report:r--
mask::r--
other::r--

Ao gerar um relatório com o aplicativo, no entanto, a máscara se propaga para o novo arquivo

[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::r-x                      #effective:---
group:report:r--                #effective:---
mask::---
other::---

Esse comportamento é esperado e estou simplesmente interpretando mal a terminologia envolvida? Eu senti falta de uma bandeira ou opção em algum lugar, estou me aproximando da direção errada?

    

Answer 1

[Primeiro de tudo, parece que seu bit SUIG está perdido (eu esperaria um "flags: -s-" na saída getfacl). No entanto, não é isso que está causando o problema aqui.]

Parece que o gerador de relatórios não apenas cria o arquivo com um 027 como umask, mas também faz um chmod () explícito no arquivo. Quando isso acontece, a máscara POSIX ACL é perdida.

Tente o seguinte (como root):

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

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

Parece que o chmod () explícito estraga as coisas.

    

Answer 2

Esse é o comportamento padrão, porque os arquivos quando criados têm a associação user: group do usuário que os cria. Ainda há esperança, no entanto. Você só precisa garantir que, quando o aplicativo for executado, ele seja executado por um usuário que tenha o grupo de relatórios como grupo principal. Existem muitos exemplos de como fazer isso por aí. Se você observar alguns dos scripts em /etc/init.d, quase todos eles fazem isso ao iniciar um serviço. Boa sorte! (Em uma nota lateral, isso mostra que você é um administrador do Windows, uma vez que todas as permissões herdadas em objetos filho são o padrão em permissões de estilo do windows, a mudança mental para acl do estilo unix em arquivos pode ser um pouco complicada.)