Omówienie bitów trybu w usłudze Azure NetApp Files
Uprawnienia dostępu do plików w systemie plików NFS ograniczają możliwości użytkowników i grup po zamontowaniu woluminu NAS. Bity trybu to kluczowa funkcja uprawnień plików NFS w usłudze Azure NetApp Files.
Bity trybu NFS
Uprawnienia bitów trybu w systemie plików NFS zapewniają podstawowe uprawnienia dla plików i folderów przy użyciu standardowej reprezentacji liczbowej kontroli dostępu. Bity trybu mogą być używane z systemem plików NFSv3 lub NFSv4.1, ale bity trybu są standardową opcją zabezpieczania systemu plików NFSv3 zgodnie z definicją w dokumencie RFC-1813. W poniższej tabeli pokazano, jak te wartości liczbowe odpowiadają mechanizmom kontroli dostępu.
| Tryb liczbowy bitowy |
|---|
| 1 — wykonywanie (x) |
| 2 — zapis (w) |
| 3 — zapis/wykonanie (wx) |
| 4 — odczyt (r) |
| 5 — odczyt/wykonanie (rx) |
| 6 — odczyt/zapis (rw) |
| 7 — odczyt/zapis/wykonanie (rwx) |
Wartości liczbowe są stosowane do różnych segmentów kontroli dostępu: właściciel, grupa i wszyscy inni, co oznacza, że nie ma szczegółowych kontroli dostępu użytkowników dla podstawowego systemu plików NFSv3. Na poniższej ilustracji przedstawiono przykład sposobu konstruowania trybu kontroli dostępu bitowego do użycia z obiektem NFSv3.
Usługa Azure NetApp Files nie obsługuje list ACL POSIX. W związku z tym szczegółowe listy ACL są możliwe tylko w przypadku systemu plików NFSv3 w przypadku używania woluminu stylu zabezpieczeń NTFS z prawidłowym system UNIX mapowania nazw systemu Windows za pośrednictwem usługi nazw, takiej jak Active Directory LDAP. Alternatywnie możesz użyć list ACL NFSv4.1 z usługami Azure NetApp Files i NFSv4.1.
W poniższej tabeli porównano stopień szczegółowości uprawnień między bitami trybu NFSv3 i listami ACL NFSv4.x.
| Bity trybu NFSv3 | Listy ACL NFSv4.x |
|---|---|
|
|
Aby uzyskać więcej informacji, zobacz Understand NFSv4.x access control list ACL (Omówienie list kontroli dostępu NFSv4.x).
Lepkie bity, setuid i setgid
W przypadku korzystania z bitów trybu z instalacją systemu plików NFS własność plików i folderów jest oparta na uid i gid użytkownika, który utworzył pliki i foldery. Ponadto po uruchomieniu procesu jest uruchamiany jako użytkownik, który go rozpoczął, a tym samym będzie miał odpowiednie uprawnienia. Przy użyciu specjalnych uprawnień (takich jak setuid, setgid, sticky bit) to zachowanie można kontrolować.
Setuid
Bit setuid jest wyznaczony przez "s" w części wykonywania uprawnienia właściciela. Bit setuid umożliwia uruchamianie pliku wykonywalnego jako właściciel pliku, a nie jako użytkownik próbujący wykonać plik. Na przykład /bin/passwd aplikacja ma setuid domyślnie włączony bit, dlatego aplikacja jest uruchamiana jako katalog główny, gdy użytkownik próbuje zmienić hasło.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
setuid Jeśli bit zostanie usunięty, funkcja zmiany hasła nie będzie działać prawidłowo.
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
Po przywróceniu bitu setuid aplikacja passwd działa jako właściciel (główny) i działa prawidłowo, ale tylko dla użytkownika uruchamiającego polecenie passwd.
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid nie ma wpływu na katalogi.
Setgid
Bit setgid może być używany zarówno w plikach, jak i katalogach.
W przypadku katalogów zestaw setgid może służyć jako sposób dziedziczenia grupy właścicieli plików i folderów utworzonych poniżej katalogu nadrzędnego z zestawem bitów. Podobnie jak setuid, bit wykonywalny jest zmieniany na "s" lub "S".
Uwaga
Capital "S" oznacza, że bit wykonywalny nie został ustawiony, na przykład jeśli uprawnienia w katalogu to "6" lub "rw".
Na przykład:
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
W przypadku plików setgid zachowuje się podobnie do setuid— pliki wykonywalne są uruchamiane przy użyciu uprawnień grupy właściciela grupy. Jeśli użytkownik znajduje się w grupie właścicieli, powiedział, że użytkownik ma dostęp do uruchamiania pliku wykonywalnego po ustawieniu setgid. Jeśli nie są one w grupie, nie uzyskują dostępu. Jeśli na przykład administrator chce ograniczyć, którzy użytkownicy mogą uruchamiać mkdir polecenie na kliencie, mogą użyć polecenia setgid.
/bin/mkdir Zwykle ma 755 uprawnień z własnością katalogu głównego. Oznacza to, że każdy może działać mkdir na kliencie.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Aby zmodyfikować zachowanie, aby ograniczyć, którzy użytkownicy mogą uruchamiać mkdir polecenie, zmień grupę będącą właścicielem mkdir aplikacji, zmień uprawnienia na /bin/mkdir 750, a następnie dodaj bit setgid na mkdir.
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
W związku z tym aplikacja jest uruchamiana z uprawnieniami dla programu group1. Jeśli użytkownik nie jest członkiem group1programu , użytkownik nie uzyska dostępu do uruchomienia mkdirprogramu .
User1 jest członkiem programu group1, ale user2 nie jest:
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
Po tej zmianie można uruchomić mkdirpolecenie , ale user2 nie może, ponieważ user2 nie znajduje się w pliku group1. user1
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
Lepki bit
Bit sticky jest używany tylko dla katalogów i, gdy jest używany, kontroluje, które pliki można modyfikować w tym katalogu niezależnie od ich uprawnień bitów trybu. Gdy bit sticky jest ustawiony, tylko właściciele plików (i katalog główny) mogą modyfikować pliki, nawet jeśli uprawnienia do plików są wyświetlane jako "777".
W poniższym przykładzie katalog "sticky" znajduje się w woluminie Usługi Azure NetApp Fils i ma szerokie otwarte uprawnienia, ale bit sticky jest ustawiony.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Wewnątrz folderu znajdują się pliki należące do różnych użytkowników. Wszystkie mają 777 uprawnień.
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
Zwykle każda osoba może modyfikować lub usuwać te pliki. Jednak ponieważ folder nadrzędny ma ustawiony lepki bit, tylko właściciele plików mogą wprowadzać zmiany w plikach.
Na przykład użytkownik user1 nie może modyfikować ani usuwać user2-file:
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
Z drugiej strony nie można modyfikować ani usuwaćuser1-file, user2 ponieważ nie są właścicielami pliku i bit lepki jest ustawiony w katalogu nadrzędnym.
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
Katalog główny może jednak nadal usuwać pliki.
# rm UNIX-file
Aby zmienić możliwość modyfikowania plików przez katalog główny, musisz usunąć katalog główny z innym użytkownikiem za pomocą reguły zasad eksportowania usługi Azure NetApp Files. Aby uzyskać więcej informacji, zobacz root squashing (Usuwanie klucza głównego).
Umask
W operacjach systemu plików NFS uprawnienia można kontrolować za pomocą bitów trybu, które wykorzystują atrybuty liczbowe do określania dostępu do plików i folderów. Te bity trybu określają atrybuty odczytu, zapisu, wykonywania i specjalne. W postaci liczbowej uprawnienia są reprezentowane jako:
- Wykonywanie = 1
- Odczyt = 2
- Zapis = 4
Łączne uprawnienia są określane przez dodanie lub odjęcie kombinacji powyższego. Na przykład:
- 4 + 2 + 1 = 7 (może zrobić wszystko)
- 4 + 2 = 6 (odczyt/zapis)
Aby uzyskać więcej informacji, zobacz system UNIX Uprawnienia Pomoc.
Maska Umask to funkcja, która umożliwia administratorowi ograniczenie poziomu uprawnień dozwolonych klientowi. Domyślnie maska u dla większości klientów jest ustawiona na 0022. 0022 oznacza, że pliki utworzone na podstawie tego klienta mają przypisaną maskę umask. Maska umask jest odejmowana od podstawowych uprawnień obiektu. Jeśli wolumin ma uprawnienia 0777 i jest instalowany przy użyciu systemu plików NFS do klienta z maską umask 0022, obiekty zapisane z klienta do tego woluminu mają dostęp 0755 (0777 – 0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
Jednak wiele systemów operacyjnych nie zezwala na tworzenie plików z uprawnieniami wykonywania, ale zezwalają folderom na odpowiednie uprawnienia. W związku z tym pliki utworzone za pomocą maski umask 0022 mogą skończyć się uprawnieniami 0644. W poniższym przykładzie użyto systemu RHEL 6.5:
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file