Несколько вопросов по ACL.

[жучара]

Друзья! С вашего позволения, а то я устану на каждую их ошибку тему создавать, а узнавать-то надо.

man setfacl
...
To help the user ensure these rules, setfacl creates entries from existing entries under the following conditions:

* If an ACL contains named user or named group entries, and no mask entry exists, a mask entry containing the same permissions as the group entry is created.

If an ACL contains named user or named group entries, and no mask entry exists

Это вообще как может быть, чтобы была запись для именованного (читай: не владельца, не члена группы, не другого(читай: левого пользователя)) пользователя и не было маски?

...Запись для левого пользователя создаётся этим же инструментом setfacl и ОБЯЗАТЕЛЬНО тут же добавляется маска (даже если использовать опцию -n маска всё равно создастся, просто она не пересчитается, но сейчас не об этом).

Это во-первых. Во-вторых, закон: есть запись для левого пользователя- есть маска.

man acl:
...
VALID ACLs
...
An ACL that contains entries of ACL_USER or ACL_GROUP tag types must contain exactly one entry of the ACL_MASK tag type.

и ещё:

man setfacl
...
Whenever an ACL contains named user entries or named group objects, it must also contain an effective rights mask.

Offtopic

(я так понимаю, когда мы говорим об эффективной маске и о просто маске, это одно и тоже потому, что маска вообще одна: ACL_MASK, а других нет. Есть ещё какая-то default ACL_MASK, но это совсем другой разговор)

Но нет же, вполне себе допускается, что левый пользователь будет, а маски не будет. Кошмар какой. Или я не понимаю чего? (случаи ручного наглого вмешательства в расширенные атрибуты не рассматриваем). Спасибо, кто откликнется. Debian 12.

[жучара]

Ну что ребята, будут какие-нибудь мысли? Тезисно если:
1) ACL без маски быть не может
2) ACL без маски быть может

[/dev/random]

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

[жучара]

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

Спасибо. Я так и думал, что они ерунду написали. Но продолжим наши изыскания. Теперь рассмотрим как наследуются права, которые default ACL. Наследуются они вот так:

Shell

man acl
...
...
1. The new object inherits the default ACL of the containing directory as its access ACL.

2. The access ACL entries corresponding to the file permission bits are modified so that they con‐
tain no permissions that are not contained in the permissions specified by the mode parameter.

1) Создадим папку foo и дадим на неё какие-нибудь минимальенькие права ACL. Например, левому пользователю fima разрешим rwx:

Shell

$ mkdir foo
$
$ sudo setfacl -m u:fima:rwx foo
$
$
$ getfacl foo
# file: foo
# owner: user
# group: user
user::rwx
user:fima:rwx
group::r-x
mask::rwx
other::r-x

$

Теперь все эти папочные права ACL сделаем дефолтными:

Shell

$ getfacl foo | setfacl -d --set-file=- foo
$
$ getfacl foo
# file: foo
# owner: user
# group: user
user::rwx
user:fima:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:fima:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

$

А теперь в папке foo создадим файл bar и посмотрим его права ACL:

Shell

$ touch foo/bar
$
$ getfacl foo/bar
# file: foo/bar
# owner: user
# group: user
user::rw-
user:fima:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--

$

Видие масочные права mask::rw-? Согласно пункту первому

1. The new object inherits the default ACL of the containing directory as its access ACL.

Они должны наследоваться. то есть быть mask::rwx. А пункт второй на них не распространяется. ибо гласит:

The access ACL entries corresponding to the file permission bits

А маска- она и в Африке маска. Это не file permission bits! Она должна остаться, следовательно, оставаться mask::rwx, но у неё почему-то убирается "x". Вот сижу, думаю, почему так. в man setfacl тоже ответа нет.

[жучара]

...Возможно, дебианщики взяли откуда-нибудь

Shell

man acl

и, особо не заморчиваясь, вставили его в свою ось (толком мне проверив?) Предположив это, надо найти ось, родную доля этого мана и посмотреть как ведёт себя наследование ACL

Shell

ACL(5) BSD File Formats Manual ACL(5)
...
Linux ACL March 23, 2002 Linux ACL

Но для какой оси написан этот ман? Не для debain, ибо такое поведение было уже в debain 4. А для какой тогда оси? Во freebsd 5 и 6 man 5acl отсутствует в принципе. Не знаю, что делать, не проверять же все дистрибутивы, какие есть в мире. Всё ж таки, я надеюсь, что это я чего-то недопонимаю, а не они неправильно написали.

[Bizdelnick]

Возможно, дебианщики взяли откуда-нибудь

отсюда

[жучара]

Возможно, дебианщики взяли откуда-нибудь

отсюда

, спасибо, но я имел ввиду где оно стояло с самого начала, на какой системе тык скыть.

[/dev/random]

А маска- она и в Африке маска. Это не file permission bits!

Там же подробно написано, что биты прав группы из "обычных" битов при наличии ACL соответствуют маске, а не правам группы.

[Bizdelnick]

но я имел ввиду где оно стояло с самого начала

Нигде. С чего Вы решили, что оно взято не из исходников?

[жучара]

Там же подробно написано, что биты прав группы из "обычных" битов при наличии ACL соответствуют маске, а не правам группы.

я не понимаю, почему маска искажается, а не это всё. Где-то должна искажаться (может быть), где-то не должна искажаться (может быть). При наследовании не должна искажаться. Ещё раз:

Shell

man acl
...
...
1. The new object inherits the default ACL of the containing directory as its access ACL.

2. The access ACL entries corresponding to the file permission bits are modified so that they con‐
tain no permissions that are not contained in the permissions specified by the mode parameter.

Offtopic

ЗДЕСЬ маска даже не упоминается. Где я ещё какой ман не прочёл, хз.

[жучара]

но я имел ввиду где оно стояло с самого начала

Нигде. С чего Вы решили, что оно взято не из исходников?

а исходники-то для чего пишутся, сами для себя то ли? Для какой-то системы наверное.

[ormorph]

я не понимаю, почему маска искажается, а не это всё. Где-то должна искажаться (может быть), где-то не должна искажаться (может быть). При наследовании не должна искажаться.

Зная как работает umask, то могу сделать вывод что тут то же самое, маска для каталогов и файлов рассчитывается по разному. Для каталогов 777 а для файлов 666. Вот и получается что ни каких x для создаваемых файлов быть не должно. Если создать каталог в этом каталоге то все права маски будут сохранены.

[/dev/random]

я не понимаю, почему маска искажается, а не это всё. Где-то должна искажаться (может быть), где-то не должна искажаться (может быть). При наследовании не должна искажаться.

$ man acl [...] CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS [...] If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. [...] [...] OBJECT CREATION AND DEFAULT ACLs [...] The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. [...]

[Bizdelnick]

а исходники-то для чего пишутся, сами для себя то ли? Для какой-то системы наверное.

Не понимаю, о чём Вы. Исходники часто пишутся переносимыми. В данном случае, если верить документации, для любых POSIX-совместимых систем. Если очень интересно зарыться в историю, то в первом коммите была поддержка только XFS под linux.

[жучара]

я не понимаю, почему маска искажается, а не это всё. Где-то должна искажаться (может быть), где-то не должна искажаться (может быть). При наследовании не должна искажаться.

Зная как работает umask, то могу сделать вывод что тут то же самое, маска для каталогов и файлов рассчитывается по разному. Для каталогов 777 а для файлов 666. Вот и получается что ни каких x для создаваемых файлов быть не должно. Если создать каталог в этом каталоге то все права маски будут сохранены.

а в мане другое написано. Ну давайте третий раз. Вот так наследуются права, которые default ACL

Shell

man acl
...
1. The new object inherits the default ACL of the containing directory as its access ACL.

2. The access ACL entries corresponding to the file permission bits are modified so that they con‐
tain no permissions that are not contained in the permissions specified by the mode parameter.

Вот так наследуются права ACL. Хоть для файлов, хоть для папок. И тут ни слова не сказано маске. Значит что? Значит, маска должна наследоваться "as is", а из неё убирается x

я не понимаю, почему маска искажается, а не это всё. Где-то должна искажаться (может быть), где-то не должна искажаться (может быть). При наследовании не должна искажаться.

$ man acl [...] CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS [...] If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. [...] [...] OBJECT CREATION AND DEFAULT ACLs [...] The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. [...]

Вот правда уже как-то не того. Я ведь это знаю. Давайте по русски:

1) если маска есть, то, чтобы всех запутать, её прописывают в двух местах- на месте прав группы в традиционных правах и в ACL ещё специально отводят поле под маску . А права на группу только в ACL.
2) Те права, которые не собственно ACL, а которые прописаны в ACL, но по факту являются традиционными правами, наследуются как есть, а потом модифицируются так, чтобы они не содержали разрешений, которых нет в параметре mode.
Ну то есть если мы создаём файл (touch foo), то надо чтобы по итогу его права дальше rw-r--r-- не вылезали

И опять таки, ни слова о том, как должна наследоваться маска. Самопроизвольно, короче, она наследуется.

[Bizdelnick]

а в мане другое написано

Где там написано, что этот ман притащен неведомо откуда?

[жучара]

а в мане другое написано

Где там написано, что этот ман притащен неведомо откуда?

не неведомо, а с freebsd. Я писал уже:

ACL(5) BSD File Formats Manual ACL(5)
...
Linux ACL March 23, 2002 Linux ACL

Допускаю, что во freebsd работало, как написано, то есть маска наследовалась полностью (в моём примере все три поля "rwx").
Я знаю очень мало, то что в debain 12 не работает как положено.
Остальное предположения и знающие люди могут их с лёгкостью опровергнуть или подтвердить. Но они вторичны. Первично лишь выделенное синим цветом.

[/dev/random]

Те права, которые не собственно ACL, а которые прописаны в ACL, но по факту являются традиционными правами

НЕТ.
СООТВЕТСТВИЕ МЕЖДУ ЗАПИСЯМИ ACL И БИТАМИ ФАЙЛОВЫХ ПРАВ [...] Если в ACL есть запись ACL_MASK, то групповые биты файловых прав соответствуют записи ACL_MASK [...] СОЗДАНИЕ ОБЪЕКТОВ И ЗНАЧЕНИЯ ACL ПО УМОЛЧАНИЮ [...] Записи ACL, соответствующие битам файловых прав, меняются так, чтобы не содержать разрешений, не указанных в параметре mode [...]
(выделено мной)
Иными словами, система смотрит на биты прав, указанные при создании файла (параметр mode) (в данном случае нас интересуют конкретно групповые биты), ищет соответствующую им запись ACL (для групповых битов это ACL_MASK, как указано в верхней части цитаты) и меняет её, чтобы биты, выключенные в mode, были выключены и в ACL_MASK.

[Bizdelnick]

не неведомо, а с freebsd. Я писал уже

А, вон оно что.
Во-первых, про FreeBSD там ничего нет. Во-вторых, это название раздела man. Откуда в нём взялось BSD — для меня загадка, но в самой странице этого текста нет, в чём Вы можете легко убедиться.

Добавлено (21:43):

в debain 12 не работает как положено

А как положено? Я не поленился найти черновик стандарта (так и не принятый, кстати), и там вообще ничего про наследование нет. Не исключаю, что оно даже в разных файловых системах может работать по-разному.

[жучара]

Те права, которые не собственно ACL, а которые прописаны в ACL, но по факту являются традиционными правами

НЕТ.
СООТВЕТСТВИЕ МЕЖДУ ЗАПИСЯМИ ACL И БИТАМИ ФАЙЛОВЫХ ПРАВ [...] Если в ACL есть запись ACL_MASK, то групповые биты файловых прав соответствуют записи ACL_MASK [...] СОЗДАНИЕ ОБЪЕКТОВ И ЗНАЧЕНИЯ ACL ПО УМОЛЧАНИЮ [...] Записи ACL, соответствующие битам файловых прав, меняются так, чтобы не содержать разрешений, не указанных в параметре mode [...]
(выделено мной)
Иными словами, система смотрит на биты прав, указанные при создании файла (параметр mode) (в данном случае нас интересуют конкретно групповые биты), ищет соответствующую им запись ACL (для групповых битов это ACL_MASK, как указано в верхней части цитаты) и меняет её, чтобы биты, выключенные в mode, были выключены и в ACL_MASK.

но тогда в приведённом мной примере маска не должна стать rw, она должна стать r!

===================================================

Имеем исходную папку :

Shell

$ getfacl foo
# file: foo
# owner: user
# group: user
user::rwx
user:fima:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:fima:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

$

а в ней сейчас создаём будем создавать файл bar. Обращаемся к вам:

Иными словами, система смотрит на биты прав, указанные при создании файла (параметр mode) (в данном случае нас интересуют конкретно групповые биты),

а это всего лишь бит r (из mode), согласны же вы со мной?

Offtopic

То есть если мы просто создадим файл bar, его группа будет иметь один-единственный бит r, отсюда и исходим.

Дальше пошли:

ищет соответствующую им запись ACL (для групповых битов это ACL_MASK, как указано в верхней части цитаты)

эта запись суть default:rwx, так ведь?
Ну то есть в даный момент имеем r(из mode) и rwx(ACL_MASK)

и меняет её, чтобы биты, выключенные в mode, были выключены и в ACL_MASK.

Ну так и меняем её (ACL_MASK). Было rwx(ACL_MASK). поскольку в mode присутcтвует только буква r, то и в результирующей ACL_MASK должна остаться тоже только буква r. А у нас rw.

[/dev/random]

но тогда в приведённом мной примере маска не должна стать rw, она должна стать r!

Не должна. Команда touch всегда передаёт параметр mode, равный rw-rw-rw- (см. man 1p touch, в man 1 touch это не указано). При наследовании ACL система комбинирует mode и наследуемый ACL. При отсутствии наследуемого ACL - mode и umask. Именно из-за umask у вас в отсутствии ACL touch создаёт файл с правами вроде rw-r--r-- (могут быть другие, в зависимости от установленного umask) вместо rw-rw-rw-. Но так как параметр mode равен именно rw-rw-rw-, он и комбинируется с ACL.

[жучара]

но тогда в приведённом мной примере маска не должна стать rw, она должна стать r!

Не должна. Команда touch всегда передаёт параметр mode, равный rw-rw-rw- (см. man 1p touch, в man 1 touch это не указано). При наследовании ACL система комбинирует mode и наследуемый ACL. При отсутствии наследуемого ACL - mode и umask. Именно из-за umask у вас в отсутствии ACL touch создаёт файл с правами вроде rw-r--r-- (могут быть другие, в зависимости от установленного umask) вместо rw-rw-rw-. Но так как параметр mode равен именно rw-rw-rw-, он и комбинируется с ACL.

Понятно, фактически тут идёт перерасчёт маски, просто он скрытый. Все права, из которых маска состоит, а именно: ACL_USER, ACL_GROUP_OBJ, и ACL_GROUP просто урезаются до значения rw таким вот извращённым способом.
Вопросы, остаются, конечно, к создателям сего. Например, почему они в таком случае не делают ещё один шаг- не урезают ACL_USER и ACL_GROUP_OBJ (а также ACL_GROUP, если бы он был) до уровня маски? Всё равно эти права работать не будут. В приведённом мной примере:

Shell

user:fima:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-

надо убрать x у user:fima:rwx и x у group::r-x и хорошо бы, чтобы это делалось автоматом.
Ну это ладно, это уже придирки. Спасибо.

[/dev/random]

Понятно, фактически тут идёт перерасчёт маски, просто он скрытый. Все права, из которых маска состоит, а именно: ACL_USER, ACL_GROUP_OBJ, и ACL_GROUP просто урезаются до значения rw таким вот извращённым способом.

Это не перерасчёт, это урезание. ACL_USER_OBJ урезается до первого rw- из параметра mode, ACL_MASK - до второго rw-, а ACL_OTHER - до третьего. Остальное не трогается. Каждая из трёх групп битов урезает запись ACL, соотвествующую (как описано в цитате из мана) этим битам. Остальные записи работают так, как будто урезаны (но по факту не урезаются) до получившегося в результате ACL_MASK, т.к. именно для этого ACL_MASK и предназначен.

Перерасчёт маски - это когда новая ACL_MASK составляется из тех записей, которые она ограничивает, так, чтобы она их не ограничивала. Здесь этого не происходит.