В начале у меня такие разрешения для файла:
# file: jar
# owner: my_user
# group: my_user
user::rw-
group::rw-
other::r--
После выполнения этого:
setfacl -m u:my_user:--- jar
и получаю такие разрешения:
# file: foobar
# owner: my_user
# group: my_user
user::rw-
user:my_user:---
group::rw-
mask::rw-
other::r--
Я ожидал, что my_user
не будет иметь разрешения на чтение (например) этого файла, но он имеет...
Почему вы этого ожидали?
Из справочной страницы man setfacl
:
Утилита setfacl распознает следующий ACL форматы ввода (для ясности вставлены пробелы):
[d [efault]:] [u [ser]:] uid [: perms]
Разрешения указанного пользователя. Разрешения владельца файла, если uid пуст.
[d [efault]:] g [roup]: gid [: perms]
Разрешения указанной группы. Разрешения группы-владельца, если gid пуст.{{1} }
[d [efault]:] m [ask] [:] [: perms]
Маска действующих прав
[d [efault]:] o [ther] [:] [: perms]
Разрешения других лиц.
ACL отделены от традиционных элементов управления доступом Unix - владельца, группы и маски прав для владельца, группы и других.
Хотя мы не можем придумать ни одной причины, по которой вам может понадобиться ACL с тем же пользователем или группой, что и традиционные средства управления доступом, решение о том, что это должно быть запрещено, не входит в философию Unix. setfacl
с радостью позволяет вам это делать; KISS хорош.
Если вам не нравится такое поведение, и вы бы предпочли, чтобы утилита «автоматически определяла» эту ситуацию, вы можете написать свою собственную оболочку вокруг setfacl
. В сценарии оболочки вы можете использовать stat -c% U FILE
для получения имени владельца и stat -c% G FILE
для имени группы файла или каталога. ФАЙЛ
. По моему опыту, в организациях со сложным набором пользователей и групп такие оболочки - не только для setfacl
, но и для всего управления владением файлами - повсеместны.
Попробуйте следующую команду:
setfacl -m u::--- jar
С помощью этого коммандос вы обращаетесь к владельцу.