O que eu posso mudar com o meu comando nagios para que ele honre a pasta de destino ACL?

Question

Eu tenho um comando nagios notifcation que se parece com isso:

/usr/bin/printf "%b" "NotificationType=$NOTIFICATIONTYPE$\nService=$SERVICEDESC$\nHost=$HOSTALIAS$\nAddress=$HOSTADDRESS$\nState=$SERVICESTATE$\nDateTime=$LONGDATETIME$\nAdditionalInfo=$SERVICEOUTPUT$\n" > $$(mktemp -p $CONTACTADDRESS1$ service.XXXXXXXX.alert)

Adicionando novas linhas de legibilidade

/usr/bin/printf "%b" 
"NotificationType=$NOTIFICATIONTYPE$\nService=$SERVICEDESC$\nHost=$HOSTALIAS$\nAddress=$HOSTADDRESS$\nState=$SERVICESTATE$\nDateTime=$LONGDATETIME$\nAdditionalInfo=$SERVICEOUTPUT$\n" 
> $$(mktemp -p $CONTACTADDRESS1$ service.XXXXXXXX.alert)

Isso realmente cria um novo arquivo no diretório definido por $CONTACTADDRESS1$ , que no meu caso é /home/alert/NagiosAlerts . Apenas recentemente investigando permissões e ACLs com essa profundidade, eu entendi que precisava definir o GID e algumas ACLs padrão para essa pasta para garantir que meu usuário nagios pudesse gravar nesse diretório e que meu usuário de alerta pudesse ler e gravar em arquivos criado aqui. Então eu configurei o seguinte

# setfacl -Rdm g:nagios:rw /home/alert/NagiosAlerts/
# setfacl -Rm g:nagios:rw /home/alert/NagiosAlerts/

Portanto, as permissões da pasta ficam assim agora

[kanmonitor01]# pwd
/home/alert/NagiosAlerts
[kanmonitor01]# ll ..
total 4
drwxrws---+ 2 alert nagios 4096 Dec 21 14:27 NagiosAlerts
[kanmonitor01]# getfacl .
# file: .
# owner: alert
# group: nagios
# flags: -s-
user::rwx
group::rwx
group:nagios:rw-
mask::rwx
other::---
default:user::rwx
default:group::rw-
default:group:nagios:rw-
default:mask::rw-
default:other::---

Então, como o usuário nagios eu toco um novo arquivo ....

[nagios@kanmonitor01]$ whoami
nagios
[nagios@kanmonitor01]$ touch file.bagel
[nagios@kanmonitor01]$ ll file.bagel
-rw-rw----+ 1 nagios nagios 0 Dec 21 14:57 file.bagel

Isso parece certo para mim. A permissão de grupo do arquivo é rw - que eu acho que é o resultado esperado. No entanto, quando o serviço nagios executa o comando no início da pergunta, acabo com isso:

[@kanmonitor01]# ll service.iCSThqzg.alert
-rw-------+ 1 nagios nagios 178 Dec 21 14:51 service.iCSThqzg.alert

[kanmonitor01]# getfacl service.iCSThqzg.alert
# file: service.iCSThqzg.alert
# owner: nagios
# group: nagios
user::rw-
group::rw-                      #effective:---
group:nagios:rw-                #effective:---
mask::---
other::---

Por isso, tem uma ACL que não é a que eu queria que ela tivesse. Isso para mim não é o comportamento esperado. Eu vejo muita pergunta sobre certos binários não honrar o ACL por causa do comportamento padrão e tal. Parece que o meu caso é que mktemp está de alguma forma me causando esse problema. Eu estava tentando evitar algum tipo de necessidade de fazer um chmod de cada arquivo sempre que eu precisasse.

Não tenho certeza do que é um bom curso de ação aqui. No final do dia, preciso que o usuário nagios possa gravar arquivos nesse diretório e que o usuário esteja alerta para poder ler / gravar esses mesmos arquivos. ACL parece ser o caminho a percorrer .....

    

Answer 1

mktemp cria explicitamente o arquivo com permissões 0600

$ strace -e open mktemp -p .
[...]
open("./tmp.EuTEGOcoEJ", O_RDWR|O_CREAT|O_EXCL, 0600) = 3

Assim, isso substitui essas ACLs padrão. mktemp pede grupo e outro não tem permissões. Uma maneira de enganá-lo para que isso não aconteça seria errado.

Você poderia chmod o arquivo após a criação (vá contra a vontade do mktemp depois):

file=$(mktemp....) && chmod g+r -- "$file" && ... > "$file"

Ou use mktemp para encontrar o nome do arquivo, mas não criá-lo, e deixe o redirecionamento do shell criá-lo:

umask 077; ... > "$(mktemp -u ...)"

Nesse caso, a ACL tem precedência sobre o umask .

O -u (aqui para o GNU mktemp ) é para inseguro mas como mktemp tentará criar um nome de arquivo exclusivo, ele não pode garantir que o arquivo ganhou t ser criado (possivelmente como um link simbólico para algum outro lugar que é o tipo de coisa com que alguém pode precisar se preocupar aqui) entre o momento em que ele é gerado e o shell o abre. Mesmo set -o clobber não pode protegê-lo, pois também tem uma condição de corrida (você precisaria de zsh ' sysopen -o excl here).