Dlaczego FreeBSD stracił maskę w, ale Debian ją zachował?


10

Próbuję zrozumieć różnicę w zachowaniu między listami ACL systemu FreeBSD i listami ACL systemu Linux. W szczególności mechanizm dziedziczenia domyślnych list ACL.

Użyłem następujących rzeczy zarówno w Debianie 9.6, jak i 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

Otrzymuję następujące dane wyjściowe z Debiana 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

Zauważ, że pliki outsidei insidemają różne uprawnienia. W szczególności outsideplik ma -rw-r--r--, który jest domyślny dla tego użytkownika i insideplik ma -rw-rw----, uwzględniając domyślne listy ACL, które przypisałem do storagekatalogu.

Dane wyjściowe tego samego skryptu we 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

(Uwaga: Debian getfaclpokaże także domyślne listy ACL, nawet jeśli nie używa tego, -dco nie ma w FreeBSD, ale nie sądzę, że rzeczywiste listy ACL storagesą inne.)

Tutaj, outsidea insidepliki mają także różne uprawnienia, ale insideplik nie ma prawa zapisu grupa, która wersja Debiana robi, prawdopodobnie dlatego, że maska w Debianie zachował wnatomiast maska w FreeBSD stracił w.

Dlaczego FreeBSD stracił wmaskę, ale Debian ją zachował?


1
Co getfacl storagewyświetla się w obu systemach?
Mikel

Czy to działa identycznie, jeśli nie używasz lepkiej grupy bitów ( g+s)?
sebasth

@Mikel Zaktualizowałem oryginalną treść pytania, aby wyświetlić getfaclinformacje.
Roxy

@sebasth Zaktualizowałem oryginalne pytanie, aby usunąć bit setgid. To nie ma znaczenia.
Roxy

Po ustawieniu ACL na storage, ls powinienem pokazać+ , podobnie oczekiwałbym, że getfaclwyjście będzie podobne do tego, co masz w systemie Debian. Czy setfaclkod zakończenia powodzenia powrócił?
sebasth

Odpowiedzi:


1

W skrócie powiedziałbym (zakładam), że używają umask inaczej.

0022 jest dokładnie rozbrojony na inne grupy W. Możesz zmienić umask, aby usunąć zakaz zapisu i sprawdzić wynik.

Powołując się na instrukcję Solaris aka SunOS (a także komentarze), ponieważ wydaje się to dość powiązane: „… Umask (1) nie zostanie zastosowany, jeśli katalog zawiera domyślne wpisy ACL.…”


1
Czy jedno jest dobre, a drugie złe? Czy istnieje standard, do którego należy się stosować?
Roxy,

Nie jestem ekspertem w tej dziedzinie, ale (jak na ironię) człowiek WEB FreeBSD ma wpis dotyczący „kanonicznej” (prawdopodobnie) implementacji (SunOS), która wyraźnie mówi, że umask nie powinien być liczony: freebsd.org/cgi/man.cgi?query= setfacl & manpath = SunOS + 5.10
poige

„… Umask (1) nie zostanie zastosowany, jeśli katalog zawiera domyślne wpisy ACL.…”
poige

Strona podręcznika FreeBSD nie jest wspomniana umask, więc wydaje się, że jest to niedefiniowane zachowanie. Czy implementacja ACL FreeBSD ma działać tak samo jak SunOS?
Roxy

Oczywiście nie powoduje to (nie wspomina), w przeciwnym razie byłaby wyraźnie widoczna sprzeczność między rzeczami stwierdzonymi i wykonanymi.
poige
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.