Общие сведения о битах режима в Azure NetApp Files
Разрешения доступа к файлам в NFS ограничивают возможности пользователей и групп после подключения тома NAS. Биты режима — это ключевая функция разрешений файлов NFS в Azure NetApp Files.
Биты режима NFS
Разрешения битов в режиме в NFS предоставляют базовые разрешения для файлов и папок, используя стандартное числовое представление элементов управления доступом. Биты режима можно использовать с NFSv3 или NFSv4.1, но биты режима являются стандартным вариантом защиты NFSv3, как определено в RFC-1813. В следующей таблице показано, как эти числовые значения соответствуют элементам управления доступом.
| Числовой бит в режиме |
|---|
| 1 — выполнение (x) |
| 2 — запись (w) |
| 3 — запись и выполнение (wx) |
| 4 — чтение (r) |
| 5 — чтение и выполнение (rx) |
| 6 — чтение и запись (rw) |
| 7 — чтение и запись и выполнение (rwx) |
Числовые значения применяются к разным сегментам управления доступом: владельцу, группе и всем остальным, что означает, что для базовых NFSv3 нет детализированных элементов управления доступом пользователей. На следующем рисунке показано, как можно создать управление доступом в режиме для использования с объектом NFSv3.
Azure NetApp Files не поддерживает списки ACL POSIX. Таким образом, детализированные списки управления доступом возможны только при использовании тома стиля безопасности NTFS с допустимыми сопоставлениями имен UNIX с Windows через службу имен, например ACTIVE Directory LDAP. Кроме того, можно использовать NFSv4.1 с Azure NetApp Files и списками ACL NFSv4.1.
В следующей таблице сравнивается степень детализации разрешений между битами режима NFSv3 и NFSv4.x ACL.
| Биты режима NFSv3 | Списки управления доступом NFSv4.x |
|---|---|
|
|
Дополнительные сведения см. в статье "Общие сведения об управлении доступом NFSv4.x" списки списков управления доступом.
Липкие биты, setuid и setgid
При использовании битов режима с подключениями NFS владение файлами и папками основано на uid gid пользователях, создающих файлы и папки. Кроме того, при запуске процесса он запускается от имени пользователя, запускающего его, и таким образом, будет иметь соответствующие разрешения. С помощью специальных разрешений (таких как setuid, setgidлипкий бит), это поведение можно контролировать.
Setuid
Бит setuid назначается значением "s" в части выполнения бита владельца разрешения. Бит setuid позволяет запускать исполняемый файл от имени владельца файла, а не как пользователь пытается выполнить файл. Например, /bin/passwd приложение имеет бит, включенный setuid по умолчанию, поэтому приложение запускается в качестве корневого каталога, когда пользователь пытается изменить свой пароль.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
setuid Если бит удален, функция изменения пароля не будет работать должным образом.
# 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
setuid При восстановлении бита приложение passwd запускается как владелец (корень) и работает правильно, но только для пользователя, выполняя команду 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 не влияет на каталоги.
Setgid
Бит setgid можно использовать как в файлах, так и в каталогах.
С помощью каталогов setgid можно использовать в качестве способа наследовать группу владельцев для файлов и папок, созданных под родительским каталогом с битом. Например setuid, исполняемый бит изменяется на "s" или "S".
Примечание.
Буква "S" означает, что исполняемый бит не задан, например, если разрешения в каталоге равны "6" или "rw".
Например:
# 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
Для файлов setgid работает аналогично setuid— исполняемые файлы выполняются с помощью разрешений группы владельца группы. Если пользователь находится в группе владельцев, сказал, что пользователь имеет доступ к запуску исполняемого файла при установке setgid. Если они не в группе, они не получают доступ. Например, если администратор хочет ограничить, какие пользователи могут запустить mkdir команду на клиенте, они могут использовать setgid.
Как правило, /bin/mkdir имеет 755 разрешений с корневой собственностью. Это означает, что любой пользователь может работать mkdir на клиенте.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Чтобы изменить поведение, чтобы ограничить, какие пользователи могут запустить mkdir команду, измените группу, которая владеет mkdir приложением, измените разрешения на /bin/mkdir 750, а затем добавьте набор бита 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
В результате приложение выполняется с разрешениями для group1. Если пользователь не является членом group1, пользователь не получает доступ к запуску mkdir.
User1 является членом group1, но user2 не является:
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
После этого изменения user1 может выполняться mkdir, но user2 не может, так как user2 не выполняется 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
Липкий бит
Липкий бит используется только для каталогов и при использовании определяет, какие файлы можно изменять в этом каталоге независимо от их разрешений в режиме. Если установлен липкий бит, только владельцы файлов (и корень) могут изменять файлы, даже если разрешения на файлы отображаются как "777".
В следующем примере каталог "sticky" живет в томе Azure NetApp Fils и имеет широкие разрешения, но задается липкий бит.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Внутри папки находятся файлы, принадлежащие разным пользователям. У всех есть 777 разрешений.
# 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
Как правило, любой пользователь сможет изменять или удалять эти файлы. Но так как родительская папка имеет липкий битовый набор, только владельцы файлов могут вносить изменения в файлы.
Например, user1 не может изменять и удалять 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
И наоборот, не удается изменить и удалитьuser1-file, user2 так как они не принадлежат файлу, а липкий бит установлен в родительском каталоге.
# 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
Однако корневой каталог по-прежнему может удалить файлы.
# rm UNIX-file
Чтобы изменить способность корневого каталога изменять файлы, необходимо сквашировать корневой каталог другому пользователю с помощью правила политики экспорта Azure NetApp Files. Дополнительные сведения см. в разделе "Корневое скваширование".
Umask
В операциях NFS разрешения можно контролировать с помощью битов режима, которые используют числовые атрибуты для определения доступа к файлам и папкам. Эти биты режима определяют чтение, запись, выполнение и специальные атрибуты. Числовые разрешения представляются следующим образом:
- Execute = 1
- Чтение = 2
- Запись = 4
Общее количество разрешений определяется путем добавления или вычитания сочетания предыдущего. Например:
- 4 + 2 + 1 = 7 (может сделать все)
- 4 + 2 = 6 (чтение и запись)
Дополнительные сведения см . в справке по разрешениям UNIX.
Umask — это функция, которая позволяет администратору ограничить уровень разрешений, разрешенных клиенту. По умолчанию umask для большинства клиентов имеет значение 0022. 0022 означает, что файлы, созданные из этого клиента, назначаются umask. Umask вычитается из базовых разрешений объекта. Если том имеет разрешения 0777 и подключается с помощью NFS к клиенту с umask 0022, объекты, записанные из клиента, имеют доступ 0755 (0777 –0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
Однако многие операционные системы не позволяют создавать файлы с разрешениями на выполнение, но они позволяют папкам иметь правильные разрешения. Таким образом, файлы, созданные с помощью umask 0022, могут в конечном итоге быть разрешениями 0644. В следующем примере используется 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