Por que o FreeBSD perdeu a máscara w, mas o Debian a reteve?


10

Estou tentando entender a diferença de comportamento entre ACLs do FreeBSD e ACLs do Linux. Em particular, o mecanismo de herança para as ACLs padrão.

Eu usei o seguinte no Debian 9.6 e no FreeBSD 12:

$ cat test_acl.sh
#!/bin/sh

set -xe

mkdir storage
setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage

touch outside
cd storage
touch inside
cd ..

ls -ld outside storage storage/inside

getfacl -d storage
getfacl storage
getfacl outside
getfacl storage/inside

umask

Eu obtenho a seguinte saída do Debian 9.6:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa aaa    0 Dec 28 11:16 outside
drwxr-xr-x+ 2 aaa aaa 4096 Dec 28 11:16 storage
-rw-rw----+ 1 aaa aaa    0 Dec 28 11:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx          #effective:rw-
mask::rw-
other::---

+ umask
0022

Observe que os arquivos outsidee insidetêm permissões diferentes. Em particular, o outsidearquivo possui -rw-r--r--, que é o padrão para esse usuário e o insidearquivo -rw-rw----, respeitando as ACLs padrão que designei ao storagediretório.

A saída do mesmo script no FreeBSD 12:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa  aaa    0 Dec 28 03:16 outside
drwxr-xr-x  2 aaa  aaa  512 Dec 28 03:16 storage
-rw-r-----+ 1 aaa  aaa    0 Dec 28 03:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx      # effective: r--
mask::r--
other::---

+ umask
0022

(Nota O Debian getfacltambém mostrará as ACLs padrão, mesmo quando não estiver usando -donde o FreeBSD não, mas não acho que as ACLs reais storagesejam diferentes.)

Aqui, os arquivos outsidee insidetambém têm permissões diferentes, mas o insidearquivo não possui permissão de gravação em grupo que a versão Debian, provavelmente porque a máscara no Debian reteve o wtempo em que a máscara no FreeBSD perdeu a w.

Por que o FreeBSD perdeu a wmáscara, mas o Debian a reteve?


1
O que getfacl storagemostra nos dois sistemas?
Mikel

Isso funciona de forma idêntica se você não usar o grupo de bits fixos ( g+s)?
sebasth

@ Mikel Atualizei o conteúdo original da pergunta para mostrar as getfaclinformações.
Roxy

@sebasth Atualizei a pergunta original para remover o bit setgid. É irrelevante.
Roxy

Depois de configurar o ACL para storage, ls deve mostrar+ , da mesma forma, eu esperaria que o getfaclresultado fosse semelhante ao que você obteve no sistema Debian. Retornou o setfaclcódigo de saída com sucesso?
sebasth

Respostas:


1

Em suma, eu diria (suponha) que eles estão usando umask de maneira diferente.

0022 é exatamente o grupo-outro não-definido W. Você pode alterar umask para remover a proibição de gravação e verificar o resultado.

Citando o manual do Solaris aka SunOS (e também comentários), já que isso parece estar bastante relacionado: "… O umask (1) não será aplicado se o diretório contiver entradas padrão da ACL.…"


1
Um está certo e o outro errado? Existe um padrão que isso deva aderir?
Roxy

Eu não sou especialista nisso, mas (ironicamente), o homem da Web do FreeBSD tem entrada para implementação "canônica" (sem dúvida) (SunOS) que diz explicitamente que umask não deve ser contada: freebsd.org/cgi/man.cgi?query= setfacl & manpath = SunOS + 5.10
poige

"… O umask (1) não será aplicado se o diretório contiver entradas padrão da ACL.…"
poige

A página de manual do FreeBSD não é mencionada umask, então esse parece ser um comportamento sub-definido. A implementação de ACL do FreeBSD deveria funcionar da mesma forma que o SunOS?
Roxy

Obviamente, isso não menciona, caso contrário, seria claramente visto uma contradição entre as coisas declaradas e feitas.
Poige 31/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.