setfacl altera incorretamente permissões de grupo

Question

Para fazer backup da árvore de diretórios "/ home" de um servidor, criei uma conta de 'backup' e usei o setfacl para tornar o diretório inteiro legível por ele. Meu trabalho cron executa este comando como root a cada noite:

setfacl -R -m u:backup:rx,d:u:backup:rx /home

Ótimo, exceto por um problema: sempre que executo este comando, ele altera as permissões de grupo da minha chave ssh.

me@myserver:~/.ssh$ ls /home/me/.ssh/id_rsa -l
-rw-r-x---+ 1 me me 1679 Jan  8 18:35 /home/me/.ssh/id_rsa

Bem, isso faz com que meu programa ssh seja cancelado porque agora é legível em grupo. Estranhamente, o getfacl discorda das permissões.

me@myserver:~/.ssh$ getfacl /home/me/.ssh/id_rsa
getfacl: Removing leading '/' from absolute path names
# file: home/me/.ssh/id_rsa
# owner: me
# group: me
user::r--
user:backup:r-x
group::---
mask::r-x
other::---

O getfacl acha que o arquivo não é legível por grupo. Se eu executar o comando óbvio

chmod 400 id_rsa

a permissão é fixa, mas é revertida toda vez que eu executo novamente o comando original (setfacl -R -m u: backup: rx, d: u: backup: rx / home). O que está acontecendo?

Nota: Eu quero meu id_rsa para backup, então não vamos nos preocupar com essas implicações de segurança.

    

Answer 1

Se dermos uma olhada na página acl(5) man, vemos:

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

The permissions defined by ACLs are a superset of the permissions specified by the file permission bits.

There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permis‐ sions correspond to the permissions of the ACL_GROUP_OBJ entry. The other permissions correspond to the permissions of the ACL_OTHER_OBJ entry.

Se você observar sua getfacl saída, verá que mask é r-x , sem o qual backup não teria acesso ao arquivo.

Na verdade, esse r-x no modo não significa que o grupo me tenha acesso ao arquivo (mas não), apenas que outra pessoa (usuário ou grupo) pode ter acesso a ele .

Ainda assim, para ssh é o mesmo, não é bom o suficiente.

Quando você faz o chmod 400 , limpa a máscara, o que significa que o usuário backup não tem mais acesso a ela.

É um pouco confuso, mas é provavelmente a melhor abordagem para conciliar os dois mecanismos de permissão.

Para o seu problema, você provavelmente precisará fazer seu backup como root ou usar recursos.

    

Answer 2

Meu ssh não se comporta assim (openssh-6.0p1-2.3.3).

Seria interessante ver a saída do strace para a chamada ssh, apenas as verificações do arquivo.

Eu geralmente duvido que esta seja uma boa estratégia. Por que não usar root para backups? Ou pelo menos dê CAP_DAC_READ_SEARCH e CAP_DAC_OVERRIDE ao processo de backup (com setcap ou Apparmor)?