Вопрос или проблема
Я изучаю тему “sticky bit”, и это почти то, что мне нужно… но не совсем.
Предыстория
Я управляю небольшой инстанцией JupyterHub с тремя курсами, и у каждого курса есть преподаватель. Мне хотелось бы иметь папку на сервере для подачи файлов.
Студенты (в группе jupyterhub-users
) должны иметь возможность помещать свои файлы в папку, но не должны иметь возможность перемещать или просматривать другие файлы в папке. В идеале они должны сохранять возможность перемещать или редактировать свои собственные файлы.
Преподаватели курса (в группе jupyterhub-instructors
) должны иметь полный доступ к файлам и папкам в папке submissions
, чтобы они могли перемещать студенческие работы так, как считают нужным.
Мое текущее понимание
Я осведомлен о существовании sticky bit… моя проблема с ним заключается в том, что он оставляет других преподавателей без возможности изменять содержимое папки. Существует ли версия sticky bit, которая позволяет группе редактировать папку? В этом случае я могу установить ACL так, чтобы jupyterhub-users
имели права rwx
на папке (позволяя им подавать файлы в папку и видеть её содержимое) и установить владельца папки как root:jupyterhub-instructors
, чтобы преподаватели могли контролировать содержимое папки.
Если ничего не получится, я предполагаю, что могу создать подпапки в папке submissions
, принадлежащие каждому преподавателю, затем установить sticky bit на каждую подпапку. Я хотел бы избежать последующего обслуживания, связанного с этим, поскольку мне придется помнить о создании новой папки каждый семестр для каждого преподавателя.
Будут ли имена файлов предсказуемыми и уникальными? Если нет, установка разрешений на директорию на 0773
и владение root:jupyterhub-instructors
позволит студентам загружать файлы в директорию, но не просматривать содержимое директории. Все члены jupyterhub-instructors
будут иметь полный контроль над директорией.
Любой пользователь, который знает имя конкретного файла, сможет просмотреть его и, возможно, увидеть его содержимое в зависимости от разрешений на файл, установленных первоначальным пользователем.
Я вижу несколько подходов для решения этой задачи; ни один из них не является простым и удобным.
разделение папок и inotify 1: ввод и сбор
Вы создаете папку input
с 777
и настраиваете inotify для неё. Когда пользователь создает файл (закрывает дескриптор файла), активируется скрипт, который
- перемещает файл в директорию
775
- меняет владельца (напр., на root) и группу
- меняет разрешения на
660
- устанавливает
rw
ACE для бывшего владельца
(возможный) недостаток: пользователи могут видеть файлы других пользователей (но не их содержимое).
разделение папок и inotify 2: одна на пользователя, одна для группы
Вместо одной папки для всех вы создаете папку (770
) для jupyterhub-instructors
и по одной для каждого пользователя (700
).
Скрипт inotify
- создает жесткую ссылку в папке группы с именем файла
${username}-${original_filename}
- меняет владельца (например, на root) и группу
- меняет разрешения на
660
- устанавливает
rw
ACE для бывшего владельца
файловая система FUSE bindfs (https://bindfs.org/)
Я не тестировал это. bindfs
игнорирует sticky bit. Я не уверен, что означает “игнорирует” в этом контексте. Публичная папка будет иметь 1777
, и (где-то) ниже будет создана точка монтирования bindfs
, которая будет принуждать все файлы иметь ?6?
. Я предполагаю, что sticky bit оригинальной директории не будет препятствовать изменениям, сделанным в этом пути (но я не уверен).
NFS4 ACL
Вы монтируете директорию через NFS4 (с той же системы) и настраиваете те разрешения, которые вам нужны…
преимущество: всего одна директория
(возможный) недостаток: пользователи могут либо видеть файлы других пользователей, либо не видеть даже свои собственные.
Ответ или решение
Концепция "sticky bit" в UNIX-подобных системах применяется, прежде всего, для ограничения прав доступа к объектам внутри директории, так чтобы пользователи могли удалять или изменять только свои собственные файлы, даже если они обладают правами на запись в директорию. Ваша потребность включает в себя похожие условия, но с некоторыми нюансами, что делает задачу интересной и требующей нестандартных решений.
Теория
Sticky bit является флагом, который, при установленной на директорию или файл, предотвращает удаление или изменение содержимого файла пользователями, у которых нет на него прав. Наиболее часто sticky bit используется для того, чтобы пользователи могли удалять только свои файлы, даже если они имеют права на запись в директорию. Однако, этот подход не подходит для реализации расширенных прав группы, которая нужна в вашем случае.
Для достижения нужного поведения, возможно, потребуется использовать более сложные системы управления доступом, такие как Access Control Lists (ACL) или использование отдельных инструментов и скриптов для автоматизации управления правами.
Пример
Вы описали ситуацию, где у вас есть три группы пользователей: студенты, относящиеся к группе jupyterhub-users
, которые должны иметь возможность добавлять свои файлы в директорию для сдачи, но не должны видеть или изменять файлы других студентов. Инструкторы, принадлежащие к группе jupyterhub-instructors
, должны иметь полный контроль над директорией для выполнения своих обязанностей по проверке и организации работы.
Одним из решений этого вопроса может стать использование:
-
Access Control Lists (ACLs): ACL является расширением стандартной модели прав доступа в UNIX-системах и позволяет задать более детальную схему управления, чем это позволяет стандартная система прав владельца-группа-другие. С использованием ACL можно разрешить группе
jupyterhub-instructors
полный доступ на редактирование, в то время какjupyterhub-users
могут иметь права только на добавление и просмотр своих файлов. -
Скрипты автоматизации (inotify): Варианты с использованием inotify и скриптов могут автоматически изменять права владельца и доступа на файлы в момент их создания, тем самым обеспечивая правильное управление доступом.
-
Использование FUSE и таких утилит, как bindfs: Хотя этот вариант менее распространен, он может предоставить более гибкое управление, игнорируя некоторые ограничения стандартной файловой системы.
-
NFS4 ACL: Изменение системы хранения на файловую систему, поддерживающую сложное управление ACL, может быть более устойчивым и менее подверженным ошибкам путем.
Применение
Ваша цель – создать систему управления файлами, где студенты не могут изменять или видеть чужие файлы, однако имеют доступ к своим, а преподаватели обладают полным контролем. С использованием ACL, вы можете:
- Установить на директорию права
770
, дать группеjupyterhub-instructors
праваrwx
на директорию, что позволит преподавателям изменять и управлять всеми файлами. - Создать отдельные поддиректории для каждого учащегося, где права на эти поддиректории могут управляться отдельно, предотвращая просмотр содержимого другими пользователями.
Кроме того, инновационным решением может стать разработка скрипта на основе inotify для наблюдения за действиями в директории с последующим изменением прав и порядка размещения файлов. Это сделает вашу систему управления более автоматизированной и удобной.
Современная UNIX-система предоставляет мощные инструменты для гибкого управления правами пользователей и групп, и использование таких механизмов как ACL в сочетании со скриптами для автоматизации позволит вам добиться нужного поведения системы, упростив при этом процессы управления и поддержки инфраструктуры.