facl, setfacl, udział w katalogu, dlaczego cp umieszcza uprawnienia oryginalnego pliku w masce facl? Czy nie powinno być ' czy to powinno być zachowanie cp -p?

Użytkownicy tego systemu są ostrożni i ustawiają swoje umaski na bardzo prywatne 0077. Jednak użytkownicy chcieliby mieć określone dla grup katalogi, w których pliki mogą być kopiowane, aby jawnie udostępniać je tylko innym członkom grupy. Może istnieć wiele takich katalogów udziałów, chociaż każdy jest specyficzny dla grupy.

Ustawienie „sticky bit” grupy w danym katalogu, który ma być używany do udostępniania, nie wystarczy. Chociaż ustawienie lepkiego bitu powoduje, że własność grupy jest poprawna w przypadku plików umieszczonych w katalogu, uprawnienia do tych plików są często ustawione w taki sposób, że plików nie można odczytać ani edytować, tj. Nie można ich faktycznie udostępniać. Po prostu pojawiają się na liście katalogów. Dzieje się tak, ponieważ niektórzy użytkownicy albo nie myślą, albo nie wiedzą, jak ręcznie dostosować wymagane uprawnienia grupy, aby umożliwić odczyt i zapis. Możemy im w tym zrobić przerwę, ponieważ w końcu użytkownicy nie są administratorami. Za pomocą acls można określić, że dana grupa ma dostęp do plików w katalogu współużytkowanym, niezależnie od tego, jakie byłyby uprawnienia grupy bez list ACL. To idealne rozwiązanie, ale nie do końca działa.

W dalszej części współużytkowana grupa to „customer_gateway”, a przykładowy użytkownik próbujący udostępnić plik to „svw”. Jak widać w transkrypcji, użytkownik svw jest członkiem grupy customer_gateway. Katalog, w którym ma nastąpić udostępnianie, jest również nazywany „customer_gateway /”

Poniższy tekst używa acls. Ustawiam uprawnienia grupy, domyślne uprawnienia grupy, maskę i domyślną maskę. Działa dobrze w przypadku plików utworzonych w katalogu lub plików przeniesionych tam przez cat (lub tar), ale o dziwo, nie w przypadku plików, które tam zostały „cp”:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

Pokazuje to, że gdy plik jest tworzony w katalogu, otrzymuje on domyślne uprawnienia i można go współużytkować. Ale użytkownicy nie zawsze tworzą tam swoje pliki, zwykle tam je kopiują.

Ale zrobienie kopii to to samo, ponieważ aby zrobić kopię, musimy najpierw utworzyć nowy plik. tutaj zwykła kopia, a nie kopia z zachowaniem uprawnień. Jest taka sama, jak poniższy formularz, który przy okazji działa i kopiuje plik, który będzie współdzielony w katalogu niezależnie od jego oryginalnych uprawnień grupowych:

cat < data.in > shared/data.out 

działa dobrze, działa również potokowanie przez tar, ale formularz

cp data.in shared/data.out 

nie działa. cat plik ed otrzymuje domyślną maskę i domyślne uprawnienia. Plik cp ed zachowuje swoje uprawnienia w masce ACL i uprawnienia grupy, tak jakby to było a cp -p (ale to nie było „t), a zatem efektywne uprawnienia odczytywane są jak oryginalny plik, a nie to, na co zostały ustawione listy ACL.

Jako drugą próbę przeprowadziłem ten eksperyment z group sticky bit, chmod g + rwxs, wraz z facl ch anges i otrzymałem dokładnie takie same wyniki. Chociaż listy katalogów są ładniejsze z powodu własności grupowej wyświetlanej dla wszystkich udostępnionych plików. Uruchomiłem go również z ustawionym tylko bitem sticky grupy, bez setfacl. Dało to również ten sam wynik dla skopiowanych plików (więc facle wyglądają dość bezużytecznie dla katalogu, w którym pliki są kopiowane do współdzielenia).

Na jakiej podstawie i z jakim uzasadnieniem faclowanie linux rozróżnia różne formy tworzysz dane? Po co zmuszać cp do zachowania uprawnień, skoro nie powiedziano mu, aby to zrobić? Jaki powód uzasadniałby zamieszanie spowodowane tym rozróżnieniem między kotem a pipingiem przez działanie smoły, ale cp nie działa? Czy brakuje mi magicznej inkantacji, która uczyniłaby to rozróżnienie wyparować?

Czy to podsumowanie jest poprawne: facls pozwoli ci przezwyciężyć własność współdzielenia plików, sprawi, że uprawnienia będą bardziej liberalne niż umask podczas „tworzenia” plików, chyba że to utworzenie jest spowodowane poleceniem cp i nie bez powodu, ponieważ … ponieważ dlaczego?

Komentarze

• Jakiego systemu operacyjnego (dystrybucja i wersja Linuksa) i jakiego systemu plików używasz? Czy byłoby w porządku, gdyby ludzie używali cat, może za pomocą dedykowanego do tego celu skryptu powłoki?
• Czy chcesz, aby każdy użytkownik w grupie mógł modyfikować lub usuwać dowolny plik, czy tylko twórca powinien mieć takie uprawnienia? Innymi słowy, tylko uprawnienia do odczytu (i może uprawnień do wykonywania) dla innych użytkowników.
• Debian 10. Ponieważ tworzenie plików działa, ' przepuszczałem kopie przez tar. ' ll pakiet, który pojawia się jako polecenie proj_cp w / usr / local / bin. Jeśli jednak użytkownik musi użyć specjalnego polecenia kopiowania, można po prostu przejść z grupą sticky bit bez faclów i ustawić uprawnienia. Chcę wiedzieć, jak ustawić listy ACL, aby cat tar i cp działały.Myślę, że ' jest problem z listami ACL z cp, ponieważ wykonują one zachowanie cp -p zamiast zachowania cp. I ' Z niecierpliwością czekam na kontakt z ekspertami ds. Uprawnień.
• Udostępnianie w grupie to powtarzający się problem z różnymi odmianami, jak wskazałeś. W tym przypadku programiści mają dostęp do katalogu wersji testowej. To ich sprawa. Mogą pracować w tym katalogu, wypychać, ściągać, instalować w środowisku wirtualnym itp. Problem pojawia się, gdy kopiują rzeczy z innego obszaru, w którym pracowali, a ich umaski nie są ustawione z uprawnieniami grupowymi. Jest to dla nich mylące, ponieważ tworzenie plików i kopiowanie przez tar działa dobrze. Zabawne jest również to, że muszę im dać skrypt kopiujący, który robi to, co robi cp. ' acls ' są magiczne Mówię LOL
• Nie jestem ekspertem od uprawnień, ale mam nadzieję, że moje pytania a Twoje odpowiedzi mogą pomóc ekspertom udzielić Ci odpowiednich odpowiedzi.