Исправление EvilFox, (текущая версия) :
На слово «папка» брезгливо поморщусь, но промолчу.
Ой какой брезгливый, у тебя там случаем не сектантский фанатизм?
Да, но практическое значение из этих 14 имеют только Read, Write и Execute. Кому и для чего может понадобиться, скажем, разрешение на смену владельца?
Даже и не знаю что ответить на такие утверждения. Оставлю без комментариев про практическое применение 14 прав и отвечу конкретно про смену владельца: кому? да ынтерпрайзу например, сходу тебе пример привести мне сейчас сложно (я не системный администратор), но я уже не раз встречался с ситуациями когда что-то на первый взгляд лишнее потом очень сильно пригождается в жизни, так что меньше категоричности — если есть значит кому-то надо. Тут ещё при аудите полезно.
Либо я чего-то очень не понимаю, либо наследование у POSIX есть.
И какое же наследование у POSIX ACL есть? Можешь показать пример? Только не надо показывать права по умолчанию это ≠ наследование. Наследование это когда я помещаю файл в папку и он наследует права данные ему от папки, при этом куски запрещающих правил перекроют разрешающие. Твоя же херня даёт права в этой папке только новым там созданным файлам. Из хоть каких-то решений на этот счёт я видел только bindfs через FUSE, но это нельзя назвать POSIX ACL.
Либо я снова чего-то очень не понимаю, либо опять-таки можно.
Вот такое можно?
http://i.imgur.com/rh0yfOE.png
http://i.imgur.com/9r9nb6E.png
Покажи как.
Я тоже не знаю, и судя по тому, что в стандарте (POSIX 1003.1e DRAFT 17) аудит прописан, но AFAIK нигде не реализован, единого мнения на этот счет нет.
DRAFT
Черновик с того времени так и не стал нормальной спецификацией? Тогда понятное дело почему не реализован и единого мнения нет.
Разверни мысль, будь добр.
http://users.suse.com/~agruen/acl/linux-acls/online/
In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.
The group class permissions represent the upper bound of the permissions granted by any entry in the group class. With minimal ACLs this is trivially the case. With extended ACLs, this is implemented by masking permissions (hence the name of the mask entry): permissions in entries that are a member of the group class which are also present in the mask entry are effective. Permissions that are absent in the mask entry are masked and thus do not take effect.
The owner and other entries are not in the group class. Their permissions are always effective and never masked.
http://www.opennet.ru/docs/RUS/posixacl/posixacl-security.html.gz
При установке дополнительных прав доступа, также присваивается значение и элементу ACL_MASK, маске действующих прав доступа (effective rights mask). Значения ACL_MASK определяет лимит значения режима доступа для дополнительных пользователей и групп. Т.е. если режим доступа к файлу у пользователя rwx (чтение, запись, запуск), а маска - r--(только чтение), то у пользователя реально будет только доступ на чтение. По умолчанию (если не указывать конкретно) значение маски равно максимальному доступу среди всех дополнительных пользователей и групп.
http://docscom.ru/blog/nix/98.html
Иначе говоря, маска определяет верхний предел прав доступа, которые система ACL может присваивать отдельным группам и пользователям. Концептуально эта маска аналогична команде umask, за исключением того, что маска ACL действует всегда и указывает предоставленные, а не отобранные права. Записи ACL для названых пользователей, названых групп и группы, заданной по умолчанию, могут содержать права доступа, отсутствующие в маске, но ядро будет просто их игнорировать.
А ещё такая беда:
Эта принудительная целостность атрибутов позволяет более старым программам, которые даже не подозревают о существовании ACL, достаточно успешно работать в использующей эти списки среде. Однако существует и определенная проблема. Несмотря на то что ACL-запись group:: в приведенном примере вроде и отслеживает средний набор традиционных битов режима, это не всегда так.
С точки зрения унаследованной программы файл выглядит неизменяемым, хотя в действительности он доступен для записи для любого члена группы staff. Подобная ситуация нежелательна.
Там дальше ещё почитай, не буду я всё сюда копировать.
Эти особенности происходят от того, что админ в винде — не то же самое, что рут в линухах (и прочем unix like). Эффективно запретить что-либо NT Authority\Local system нельзя, насколько мне известно.
Верно, но мы от системы не работаем. Насколько я сейчас знаю без дыр войти из под системы можно только через:
а) планировщик событий;
б) службу запущенную от учётной записи системы.
Программа PSEXEC делает вариант б — можно увидеть по помеченной на удаление службе.
Раньше ещё через команду AT легко работало. Сейчас многое поприкрывали — теперь окно не появится если попытаться так запустить ту же консоль.
Если эти краники перекрыть, админы не смогут ворочить правами через СИСТЕМУ, а через неё можно например получить права на любой объект в ФС, даже если ей запретить всё, она всё равно может сбросить права и/или назначить себя владельцем (хотя если не сбрасывать, то доступ к объекту и его правам она получить не может).
С СИСТЕМОЙ много тонкостей, у неё не для всего есть права по умолчанию, я читал она сначала их должна получить от другого пользователя, но я не вникал в программерские дебри на этот счёт, не хватает опыта. Заметил сейчас что зачем-то для Program Files стоит запрет ей сменять владельца и разрешений, видимо какой-то смысл есть.
Исходная версия EvilFox, :
На слово «папка» брезгливо поморщусь, но промолчу.
Ой какой брезгливый, у тебя там случаем не сектантский фанатизм?
Да, но практическое значение из этих 14 имеют только Read, Write и Execute. Кому и для чего может понадобиться, скажем, разрешение на смену владельца?
Даже и не знаю что ответить на такие утверждения. Оставлю без комментариев про практическое применение 14 прав и отвечу конкретно про смену владельца: кому? да ынтерпрайзу например, сходу тебе пример привести мне сейчас сложно (я не системный администратор), но я уже не раз встречался с ситуациями когда что-то на первый взгляд лишнее потом очень сильно пригождается в жизни, так что меньше категоричности — если есть значит кому-то надо. Тут ещё при аудите полезно.
Либо я чего-то очень не понимаю, либо наследование у POSIX есть.
И какое же наследование у POSIX ACL есть? Можешь показать пример? Только не надо показывать права по умолчанию это ≠ наследование. Наследование это когда я помещаю файл в папку и он наследует права данные ему от папки, при этом куски запрещающих правил перекроют разрешающие. Твоя же херня даёт права в этой папке только новым там созданным файлам. Из хоть каких-то решений на этот счёт я видел только bindfs через FUSE, но это нельзя назвать POSIX ACL.
Либо я снова чего-то очень не понимаю, либо опять-таки можно.
Вот такое можно?
http://i.imgur.com/rh0yfOE.png
http://i.imgur.com/9r9nb6E.png
Покажи как.
Я тоже не знаю, и судя по тому, что в стандарте (POSIX 1003.1e DRAFT 17) аудит прописан, но AFAIK нигде не реализован, единого мнения на этот счет нет.
DRAFT
Черновик с того времени так и не стал нормальной спецификацией? Тогда понятное дело почему не реализован и единого мнения нет.
Разверни мысль, будь добр.
http://users.suse.com/~agruen/acl/linux-acls/online/
In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.
The group class permissions represent the upper bound of the permissions granted by any entry in the group class. With minimal ACLs this is trivially the case. With extended ACLs, this is implemented by masking permissions (hence the name of the mask entry): permissions in entries that are a member of the group class which are also present in the mask entry are effective. Permissions that are absent in the mask entry are masked and thus do not take effect.
The owner and other entries are not in the group class. Their permissions are always effective and never masked.
http://www.opennet.ru/docs/RUS/posixacl/posixacl-security.html.gz
При установке дополнительных прав доступа, также присваивается значение и элементу ACL_MASK, маске действующих прав доступа (effective rights mask). Значения ACL_MASK определяет лимит значения режима доступа для дополнительных пользователей и групп. Т.е. если режим доступа к файлу у пользователя rwx (чтение, запись, запуск), а маска - r--(только чтение), то у пользователя реально будет только доступ на чтение. По умолчанию (если не указывать конкретно) значение маски равно максимальному доступу среди всех дополнительных пользователей и групп.
http://docscom.ru/blog/nix/98.html
Иначе говоря, маска определяет верхний предел прав доступа, которые система ACL может присваивать отдельным группам и пользователям. Концептуально эта маска аналогична команде umask, за исключением того, что маска ACL действует всегда и указывает предоставленные, а не отобранные права. Записи ACL для названых пользователей, названых групп и группы, заданной по умолчанию, могут содержать права доступа, отсутствующие в маске, но ядро будет просто их игнорировать.
А ещё такая беда:
Эта принудительная целостность атрибутов позволяет более старым программам, которые даже не подозревают о существовании ACL, достаточно успешно работать в использующей эти списки среде. Однако существует и определенная проблема. Несмотря на то что ACL-запись group:: в приведенном примере вроде и отслеживает средний набор традиционных битов режима, это не всегда так.
С точки зрения унаследованной программы файл выглядит неизменяемым, хотя в действительности он доступен для записи для любого члена группы staff. Подобная ситуация нежелательна.
Там дальше ещё почитай, не буду я всё сюда копировать.
Эти особенности происходят от того, что админ в винде — не то же самое, что рут в линухах (и прочем unix like). Эффективно запретить что-либо NT Authority\Local system нельзя, насколько мне известно.
Верно, но мы от системы не работаем. Насколько я сейчас знаю без дыр войти из под системы можно только через:
а) планировщик событий;
б) службу запущенную от учётной записи системы.
Программа PSEXEC делает вариант б — можно увидеть по помеченной на удаление службе.
Если эти краники перекрыть, админы не смогут ворочить правами через СИСТЕМУ, а через неё можно например получить права на любой объект в ФС, даже если ей запретить всё, она всё равно может сбросить права и/или назначить себя владельцем (хотя если не сбрасывать, то доступ к объекту и его правам она получить не может).
С СИСТЕМОЙ много тонкостей, у неё не для всего есть права по умолчанию, я читал она сначала их должна получить от другого пользователя, но я не вникал в программерские дебри на этот счёт, не хватает опыта. Заметил сейчас что зачем-то для Program Files стоит запрет ей сменять владельца и разрешений, видимо какой-то смысл есть.
