Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 bitowy numeryczny |
|---|
| 1 — wykonaj (x) |
| 2 — pisz (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 mapowaniem nazw systemu UNIX do systemu Windows za pośrednictwem usługi nazw, takiej jak Active Directory LDAP. Alternatywnie możesz użyć NFSv4.1 z usługami Azure NetApp Files i listami kontrolnymi dostępu 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).
Bit przyklejony, 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 aplikacja /bin/passwd ma domyślnie włączony bit setuid, dlatego aplikacja działa jako administrator, gdy użytkownik próbuje zmienić swoje 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 / Notatka
Capital "S" oznacza, że bit wykonywalny nie został ustawiony, na przykład jeśli uprawnienia w katalogu to "6" lub "rw".
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, ma dostęp do uruchomienia pliku wykonywalnego, gdy setgid jest ustawiony. 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.
Zwykle /bin/mkdir ma 755 uprawnień z własnością root. Oznacza to, że każdy może uruchomić 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 user1 może uruchomić mkdir, ale user2 nie może, ponieważ user2 nie znajduje się w group1.
# 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 przylepny jest używany wyłącznie dla katalogów i, kiedy jest aktywny, reguluje, które pliki można modyfikować w tym katalogu, niezależnie od ich uprawnień bitów trybu. Gdy sticky bit jest ustawiony, tylko właściciele plików (i root) 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
Natomiast user2 nie może modyfikować ani usuwać user1-file, 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
Root 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).
Maska 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 atrybuty. W postaci liczbowej uprawnienia są reprezentowane jako:
- Wykonaj = 1
- Odczyt = 2
- Zapis = 4
Łączne uprawnienia są określane przez dodanie lub odjęcie kombinacji powyższego. Przykład:
- 4 + 2 + 1 = 7 (może zrobić wszystko)
- 4 + 2 = 6 (odczyt/zapis)
Aby uzyskać więcej informacji, zobacz Pomoc dotycząca uprawnień systemu UNIX.
Umask to funkcjonalność, która umożliwia administratorowi ograniczenie poziomu uprawnień, jakie mogą być przyznane klientowi. Domyślnie umask dla większości klientów jest ustawiony na 0022. 0022 oznacza, że pliki utworzone na podstawie tego klienta mają przypisaną maskę umask. Maskę umask odejmuje się 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 przy ustawieniu maski umask 0022 mogą mieć uprawnienia 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