A partir de um script shell bash, estou criando uma pasta e armazenando o mysqldump lá. Tenho certeza de que não há nenhum comando relacionado a permissões em meu script. Para permitir que outro usuário acesse esses arquivos, usei ACL, mas quando ele tentou acessar o arquivo, obteve problema de permissão negada, e o problema é com effectivepermissões de ACL.
O proprietário do diretório é olao novo usuário que está tentando acessar a pasta ubere a pasta égettaxi
Permissões do diretório pai
[/omega/olabooktmp]# getfacl .
# file: .
# owner: ola
# group: ola
user::rwx
user:uber:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Permissões do diretório filho
[/omega/olabooktemp]# getfacl gettaxi/
# file: gettaxi/
# owner: ola
# group: ola
user::rwx
user:uber:rwx #effective:---
group::r-x #effective:---
mask::---
other::---
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Vejo que as novas gettaxipermissões de máscara de diretório são mask::---, então acho que isso está causando o problema, mas não consigo entender completamente e como resolver esse problema.
Qualquer sugestão será muito apreciada.
Obrigado.
Responder1
Você pode alterar a máscara com o seguinte comando:
setfacl -m m:rwx filename/directory
Responder2
Se entendi bem sua pergunta, o usuário olaestá criando arquivos no diretório:/omega/olabooktmp/gettaxi
e você deseja restringir o acesso a esses arquivos, mas concedendo acesso ao usuário uber.
Nota: /omega/olabooktmp/gettaxié propriedade deola
Vamos começar sem ACL ainda:
ls -ld /omega/olabooktmp/gettaxi
drwxr-x--- 2 ola ola 4096 mars 21 08:16 /omega/olabooktmp/gettaxi
Para conceder rwxpermissão para uberusar ACL você pode usar:
setfacl -m u:uber:rwx,d:u:uber:rwX,o:--- /omega/olabooktmp/gettaxi
O que permitirá uberdireitos de usuário rwxna pasta /omega/olabooktmp/gettaxie também concederárwx de como defaulte d:. XEle concede permissão para arquivos previamente presentes na pasta e concede concessões herdadas ao arquivo. E também remova todas as outras permissões otherpara restrição, é claro. O proprietário ainda tem sua própria permissão.
O resultado:
getfacl /omega/olabooktmp/gettaxi
getfacl: Removing leading '/' from absolute path names
# file: omega/olabooktmp/gettaxi
# owner: ola
# group: ola
user::rwx
user:uber:rwx
group::r-x
mask::rwx
other::---
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::---
Teste:
olacria alguns arquivos (executados como root):
su - ola -c "for i in {1..3}; do date > /omega/olabooktmp/gettaxi/$RANDOM; done"
Resultado:
ls -l /omega/olabooktmp/gettaxi/
total 32
-rw-r----- 1 ola users 32 mars 21 08:43 17606
-rw-r----- 1 ola users 32 mars 21 08:43 22286
-rw-r----- 1 ola users 32 mars 21 08:42 31484
-rw-r----- 1 ola users 32 mars 21 08:43 31848
-rw-r----- 1 ola users 32 mars 21 08:42 667
-rw-r----- 1 ola users 4 mars 21 08:16 one
-rw-r----- 1 ola users 6 mars 21 08:16 three
-rw-r----- 1 ola users 4 mars 21 08:16 two
Não pode ser acessado por um usuário normal (executado como root):
su - debian -c "ls -l /omega/olabooktmp/gettaxi"
ls: cannot open directory '/omega/olabooktmp/gettaxi': Permission denied
Mas o uber pode (executar como root):
su - uber -c "ls -l /omega/olabooktmp/gettaxi"
total 32
-rw-r----- 1 ola users 32 Mar 21 08:43 17606
-rw-r----- 1 ola users 32 Mar 21 08:43 22286
-rw-r----- 1 ola users 32 Mar 21 08:42 31484
-rw-r----- 1 ola users 32 Mar 21 08:43 31848
-rw-r----- 1 ola users 32 Mar 21 08:42 667
-rw-r----- 1 ola users 4 Mar 21 08:16 one
-rw-r----- 1 ola users 6 Mar 21 08:16 three
-rw-r----- 1 ola users 4 Mar 21 08:16 two
Se você alterar sua ACL com alguns testes, poderá remover todas as ACL com:
setfacl -R -b /omega/olabooktmp/gettaxi
E comece de novo.
Responder3
Sim, a máscara está diminuindo as permissões. A permissão efetiva é a de uma permissão e da máscara. (user:: (o usuário proprietário) e othernão é afetado pela máscara).
Você pode alterar a máscara com: por exemplosetfacl -m m:r-x file-name .
Quando você faz umls -l , se o modo termina com um +, então os bits do modo intermediário (tradicionalmente os bits do grupo) são a máscara.
Às vezes, os bits de modo são definidos de acordo com os bits do grupo em umask. Ainda não elaborei as regras sobre quando isso acontece e quando a máscara padrão é usada. Usandocp para copiar um arquivo, parece usar a extensão umask.
Uma solução alternativa
Certifique-se de que os usuários tenham seu próprio grupo e que este esteja definido como o grupo padrão. Em seguida, defina umaskcomo 007.
Responder4
Suspeito que o comportamento seja um bug. Postei sobre isso no mês passado (consulte unix.stackexchange.com/questions/570795). O que está acontecendo é que as permissões do arquivo de origem estão sendo copiadas para a máscara acl pelo comando cp. Isso é o que eu esperava para cp -p, não para cp. Descobri que posso fazer cópias usando cat
cat afile > bfile
ou canalizando através de alcatrão
(cd A; tar -cf -)|(cd B; tar-xf -)
E os ACLs são respeitados conforme o esperado.
Eu também ofereci uma recompensa para que esse comportamento do cp fosse explicado. Ninguém explicou isso. Estou pensando em preencher um relatório de bug. Ou seja, este deve ser o comportamento ´cp -p´, não o comportamento vanilla cp. (E o sistema deduziu os pontos de recompensa mesmo que ninguém pudesse dar uma resposta. Fiquei surpreso com isso também.)