Как chmod +x работает в cygwin?
Вам нужно прочитать всю главу 3.Использование учетных записей Cygwin-POSIX, разрешения и безопасности, чтобы полностью понять это.
Некоторые выдержки следуют.
POSIX учетные записи, разрешения и безопасность
В этом разделе обсуждается, как модель безопасности Windows используется в Cygwin для реализации информации учетной записи POSIX, POSIX-подобных разрешений и как используется модель аутентификации Windows, чтобы позволить приложениям cygwin переключать пользователей в POSIX-подобной манере.
Настройка POSIX-подобных прав доступа к файлам и каталогам контролируется параметром монтирования (no)acl, который по умолчанию имеет значение acl.
Начнем с краткого обзора. Обратите внимание, что этот обзор обязательно должен быть коротким. Если вы хотите узнать больше о модели безопасности Windows, см. Статью «Контроль доступа» в документации MSDN.
Концепции POSIX и, в частности, модель безопасности POSIX здесь не обсуждаются, но считаются понятными читателю. Если вы не знаете модель безопасности POSIX, поищите в Интернете документацию для начинающих.
Краткий обзор безопасности Windows
В модели безопасности Windows практически любой "объект" защищен.
"Объекты" - это файлы, процессы, потоки, семафоры и т.д.
К каждому объекту прикреплена структура данных, называемая "дескриптором безопасности" (SD). SD содержит всю информацию, необходимую для контроля того, кто может получить доступ к объекту, и для определения того, что им разрешено делать с ним или с ним. SD объекта состоит из пяти частей:
Флаги, которые контролируют несколько аспектов этого SD. Это не обсуждается здесь.
SID владельца объекта.
SID группы владельцев объектов.
Список "Записи управления доступом" (ACE), называемый "Дискреционный список управления доступом" (DACL).
Еще один список ACE, называемый "Security Access Control List" (SACL), который не имеет значения для наших целей. Мы игнорируем это здесь.
Каждый ACE содержит так называемый "Security IDentifier" (SID) и другие вещи, которые будут объяснены чуть позже. Давайте сначала поговорим о SID.
SID - это уникальный идентификатор пользователей, групп, компьютеров и доменов Active Directory (AD). SID в основном сопоставимы с идентификаторами пользователей POSIX (UID) и идентификаторами групп (GID), но являются более сложными, поскольку они уникальны для нескольких компьютеров или доменов. SID - это структура из нескольких числовых значений. Существует удобное соглашение для ввода идентификаторов безопасности в виде строки числовых полей, разделенных символами дефиса.
...
Файловые права
В NTFS и если для точки монтирования не указана опция монтирования noacl, Cygwin устанавливает права доступа к файлам, как в системах POSIX. По сути, это достигается путем определения дескриптора безопасности с соответствующими идентификаторами SID владельца и группы, а также DACL, который содержит ACE для владельца, группы и "каждого", который представляет то, что POSIX называет "другими".
Есть только одна проблема при попытке сопоставить модель разрешений POSIX с моделью разрешений Windows.
В определении "правильного" ACL есть утечка, которая запрещает определенные настройки разрешений POSIX. Официальная документация объясняет вкратце следующее:
Запрашиваемые разрешения проверяются по всем ACE пользователя, а также по всем группам, членом которых он является. Разрешения, данные в этих пользователях и группах, которым разрешен доступ, накапливаются, и результирующий набор представляет собой набор разрешений этого пользователя, предоставленных для этого объекта.
Порядок ACEs важен. Система читает их последовательно до тех пор, пока не будет отклонено одно запрошенное разрешение или не будут предоставлены все запрошенные разрешения. Чтение прекращается при выполнении этого условия. Более поздние ТУЗы не учитываются.
Все ACE, которым отказано в доступе, должны предшествовать любому доступу ACE. ACL, следующие этому правилу, называются "каноническими".
Обратите внимание, что последнее правило является предпочтением или определением правильности. Это не абсолютное требование. Все ядра Windows будут корректно работать с ACL, независимо от порядка разрешенных и запрещенных ACE. Второе правило не изменяется, чтобы получить ACE в предпочтительном порядке.
К сожалению, вкладка безопасности в диалоговом окне свойств файла в проводнике Windows настаивает на том, чтобы переставить порядок ACE в канонический порядок, прежде чем вы сможете их прочитать. Слава Богу, порядок сортировки остается неизменным, если нажать кнопку "Отмена". Но даже не думай о нажатии ОК ...
Канонические ACL не могут отразить каждую возможную комбинацию разрешений POSIX. Пример:
rw-r-xrw-
Итак, вот первая попытка создать соответствующий ACL, предполагая, что разрешения Windows имеют только три бита, как их аналог POSIX:
UserAllow: 110
GroupAllow: 101
OthersAllow: 110
Хм, из-за накопления разрешительных прав пользователь может выполнить, потому что группа может выполнить.
Вторая попытка:
UserDeny: 001
GroupAllow: 101
OthersAllow: 110
Теперь пользователь может читать и писать, но не выполнять. Лучше? Нет!
К сожалению, группа может писать сейчас, потому что другие могут писать.
Третья попытка:
UserDeny: 001
GroupDeny: 010
GroupAllow: 001
OthersAllow: 110
Теперь группа может писать не так, как задумано, но, к сожалению, пользователь может больше не писать. Как решить эту проблему?
Согласно каноническому порядку UserAllow должен следовать GroupDeny, но легко понять, что это никогда не может быть решено таким образом.
Единственный шанс:
UserDeny: 001
UserAllow: 010
GroupDeny: 010
GroupAllow: 001
OthersAllow: 110
Опять же: Это работает на всех существующих версиях Windows NT, на момент написания, по крайней мере, от Windows XP до Server 2012 R2. Только GUI не могут (или не хотят) иметь дело с этим заказом.
Исходные учетные записи POSIX, разрешения и безопасность
дальнейшее чтение
