3

Я пытаюсь выяснить, почему изменился вывод команды ls. Я имею в виду групповые разрешения для файла.

Я создал файл с именем "file" и изменил его владельца и группу:

[root@training group3]# touch file
[root@training group3]# ls -la file
-rw-r--r--. 1 root root 0 Sep  8 15:29 file
[root@training group3]# chown uczen file
[root@training group3]# chgrp group3 file
[root@training group3]# ls -la file
-rw-r--r--. 1 uczen group3 0 Sep  8 15:29 file
[root@training group3]# getfacl file
# file: file
# owner: uczen
# group: group3
user::rw-
group::r--
other::r--

Затем я добавил дополнительные права rwx для пользователя "ula":

[root@training group3]# setfacl -m u:ula:rwx file
[root@training group3]# getfacl file
# file: file
# owner: uczen
# group: group3 
user::rw- 
user:ula:rwx 
group::r-- 
mask::rwx 
other::r--

Мой вопрос заключается в том, почему вывод команды ls -la (ниже) теперь показывает "rwx" для группы по сравнению с «r--», показанным getfacl выше. Почему химическая завивка для группы была (на вид?) изменилось, если с помощью setfacl я только добавил права для какого-то пользователя (ula)

[root@training group3]# ls -la file
-rw-rwxr--+ 1 uczen group3 0 Sep  8 15:29 file

2 ответа2

6

Я не помню, где я нашел объяснение, но это в основном, чтобы избежать неожиданностей.

Большинство людей привыкли к трем наборам, видимым в ls описывающим весь доступ, который может получить каждый. Поэтому, если столбец "группа" сохранил свое первоначальное значение, он может создать случайные дыры в безопасности. Например, у вас есть этот файл ...

-rw-rwxr--+ 1 uczen group3 0 Sep  8 15:29 file

... и вы хотите запретить кому-либо, кроме владельца, писать это, поэтому вы запускаете chmod go-w и в итоге получаете следующее:

-rw-r-xr--+ 1 uczen group3 0 Sep  8 15:29 file

Теперь, если вы спешите, вы можете не заметить знак + присутствия ACL или не знать о его значении. Если есть ACL, позволяющий кому-то другому писать в этот файл, вы получите права доступа более открытые, чем ожидалось.

Обратите внимание, что это относится и к программам, а не только к людям. Некоторые программы - например, ssh - проверяют биты разрешений Unix и требуют, чтобы группа / другое вообще не имели разрешений. Если бы файл имел разрешающий ACL, ssh не знал бы этого. (Даже если кто-то обновит OpenSSH, чтобы узнать о ACL, более старые версии все равно не будут знать о них.)

Из-за этого ACL-списки POSIX имеют специальную mask: запись для установки максимума всех разрешений, предоставленных группе по умолчанию и всем членам ACL, а поле "группа" разрешений Unix изменяется для отображения значения mask: вместо группа Unix. Например, если вы выполните chmod g=rx , вы фактически установите mask::rx .

Так что, если вы видите там rw-r--r--+ , вы можете быть уверены, что никто не сможет написать этот файл, независимо от того, какие ACL могут присутствовать, и без необходимости их проверки. Точно так же, если программа видит файл с разрешениями 0600, она также может быть уверена в этом, не требуя специальных знаний о ACL POSIX (и в будущем RichACL, ACL NFSv4 или других типов - если они следуют этому особому поведению).

Обратите внимание, что getfacl прежнему перечисляет запись группы по умолчанию как group::r-- . Если вы действительно хотите изменить эту конкретную запись, вам нужно будет сделать это с помощью setfacl .

Смотрите также:

1

Ссылка в вышеприведенном посте не работает, и на этот ответ есть другой ответ: https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html

Соответственно, маска acl отображается в поле групповых разрешений, а не групповых разрешений.

Вот лучшее объяснение: https://unix.stackexchange.com/questions/65888/setfacl-incorrectly-changes-group-permissions/498907#498907

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .