Приоритет пользователя и владельца группы в правах доступа к файлу

Я просто столкнулся с чем-то неожиданным (для меня) относительно прав доступа к файлам в Linux (Arch Linux). В основном у меня есть:

• userX в groupX
• fileX userX:groupX ---rwx----

Что озадачивает меня: я не могу выполнить какие - либо действия ( rwx) на fileX. Это правильно? Может кто-нибудь подтвердить, что это действительно ожидаемое поведение?

Единственные действия , которые я могу выполнить это mvи rmпотому , что у меня есть разрешение на запись в родительском каталоге.

Дело в том, что я всегда думал, что эти разрешения рушатся друг с другом, начиная с самого общего (другое -> группа -> пользователь). Другими словами, если o=rwxкого волнует, что такое разрешения для группы и пользователя? Очевидно, это не тот случай, но для меня это не имеет особого смысла; кажется нелогичным. Единственная вещь, в которой этот подход, кажется, полезен, состоит в том, чтобы легко исключить очень определенного человека / группу, которая не кажется разумным способом пойти на это (imho). Кроме того, владелец (и группа?) Должен быть в состоянии в chmodлюбом случае правильно? Есть мысли по этому поводу?

Дело в том, что я всегда думал, что эти разрешения рушатся друг с другом, начиная с самого общего (другое -> группа -> пользователь).

Если бы это было так, то «другие» разрешения будут применяться ко всем.

Другими словами, если o = rwx, кого это волнует, какие разрешения у группы и пользователя?

Это отличается от вашего предыдущего предложения. Здесь вы подразумеваете, что разрешения объединены или объединены, например, что userX имеет разрешение на чтение, если userX владеет файлом и файл доступен для чтения пользователем, или если группа, к которой принадлежит userX, владеет файлом, а файл является группой -читаемо, или если файл доступен для чтения другим. Но это не так, как это работает. Фактически, это o=rwxозначает, что rwxразрешения применяются к другим, но это ничего не говорит о сущностях, которые не являются другими.

Во-первых, не имеет значения, к какой группе принадлежит пользователь. Ядро не имеет представления о пользователях, принадлежащих к группам. Ядро поддерживает для каждого процесса идентификатор пользователя ( эффективный UID ) и список идентификаторов группы (эффективный GID и дополнительные GID). Группы определяются во время входа в систему, процессом входа в систему - это процесс входа в систему, который считывает базу данных группы (например /etc/group). Идентификаторы пользователей и групп наследуются дочерними процессами¹.

Когда процесс пытается открыть файл с традиционными разрешениями Unix:

• Если владельцем файла является эффективный UID процесса, то используются биты прав доступа пользователя.
• В противном случае, если группа-владелец файла - это эффективный GID процесса или один из дополнительных идентификаторов группы процесса, то используются биты разрешения группы.
• В противном случае используются другие биты разрешения.

Используется только один набор битов rwx. Пользователь имеет приоритет над группой, которая имеет приоритет над другими. При наличии списков контроля доступа описанный выше алгоритм обобщается:

• Если в файле есть ACL для эффективного UID процесса, он используется для определения того, предоставлен ли доступ.
• В противном случае, если в файле есть ACL для эффективного GID процесса или один из дополнительных идентификаторов группы процесса, то используются биты разрешения группы.
• В противном случае используются другие биты разрешения.

См. Также Приоритет ACLS, когда пользователь принадлежит к нескольким группам, для получения дополнительной информации об использовании записей ACL, включая влияние маски.

Таким образом, -rw----r-- alice internsуказывает файл, который может быть прочитан и записан Алисой, и который может быть прочитан всеми другими пользователями, кроме интернов. Файл с разрешениями и владельцем ----rwx--- alice internsдоступен только для стажеров, кроме Алисы (независимо от того, является она стажером или нет). Поскольку Алиса может позвонить, chmodчтобы изменить разрешения, это не обеспечивает никакой безопасности; это крайний случай. В системах с ACL обобщенный механизм позволяет удалять разрешения у определенных пользователей или определенных групп, что иногда полезно.

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

• Это имеет полезный эффект, так как позволяет удалять разрешения из набора пользователей или групп в системах с ACL. В системах без ACL разрешения могут быть удалены из одной группы.
• Это проще реализовать: проверить один набор битов, а не объединять несколько наборов бит вместе.
• Проанализировать права доступа к файлу проще, поскольку задействовано меньше операций.

Can _{Они могут измениться при выполнении процесса setuid или setgid. Это не связано с проблемой под рукой.}

Более конкретные разрешения имеют приоритет над менее конкретными.

userX в группеX

fileX userX: groupX --- rwx ----

Поскольку вы являетесь владельцем файла, вам будут предоставлены только права владельца. Владелец не имеет разрешений. Таким образом, вы ничего не можете сделать. Если бы вы не были владельцем файла и участником группы, тогда бы применялись разрешения группы.

Пожалуйста, прочтите этот раздел вики-страницы

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- означает, что владелец имеет права на чтение, запись и выполнение, группа имеет права на чтение и запись, а другие не имеют разрешений.

Предоставленные вами разрешения дают группе groupX разрешения на чтение, запись и выполнение файла. Если вы являетесь участником группы «groupX», но не являетесь владельцем файла, эти разрешения будут применяться к вам.

В этом случае я предполагаю, что вы действительно являетесь владельцем файла. Только разрешения, установленные для владельца, будут применяться к вам. Конечно, владелец может переопределить или изменить права доступа к файлу. Группа, однако, не может этого сделать. Например, vim предложит вам подтвердить, пишете ли вы в файл, к которому у вас нет прав на запись, но вы являетесь владельцем.

Я обычно читаю разрешения слева направо. Я владелец? Если да, применяются разрешения владельца. Если не; я член группы? Если да, применяются групповые разрешения. Если нет, то разрешения для «Другое» относятся ко мне.

В некоторых случаях полезно быть владельцем файла, но не иметь разрешения на запись. Он защищает вас от случайного удаления или изменения файла. Лично я установил разрешение 400 для всех моих файлов шаблонов, просто чтобы убедиться, что я не изменил их случайно. То же самое касается разрешений на выполнение.

Я смог добавить пользователя в группу, дать группе разрешения на доступ к каталогу (070), а затем ПОСЛЕ ПЕРЕЗАПУСКА смог получить доступ к папке.

Создать группу: sudo groupadd groupname

Добавить пользователя в группу: sudo gpasswd -a имя пользователя имя группы

Убедитесь, что весь каталог находится в правильном владении группой (для выполнения должен быть текущий член имени группы): sudo chgrp -R имя_группы directory_path /

Укажите для группы только группу rwx (может быть просто rw, при необходимости измените ее): sudo chmod -R 070 directory_path

После выполнения вышеуказанных действий обязательно выйдите из системы и снова войдите в систему. Если это не помогло, перезагрузите компьютер. Это помогло мне.