Безопасно делиться каталогами с пользователями процесса

Question

Предположим, у меня есть каталог /clients/bob который принадлежит bob:bob

Я мог бы предоставить разработчикам группу bob чтобы они могли редактировать эти файлы, и затем я смогу удалить их из этой группы, когда им больше не нужен доступ.

Однако что мне делать с пользователями процессов, такими как www-data? Я не хочу помещать www-data в группу bob потому что это даст Apache доступ ко всему, а не только к корню документа на сайте. Я также не хочу передавать права собственности на корневой каталог документа bob:www-data или www-data:bob потому что это решение не масштабируется, когда мне нужно предоставить двум пользователям процесса доступ к каталогу (предположим, у меня есть cronjob работает на другого пользователя)

Answer 1

Вы должны рассматривать пользователя www-data как «всех» и предоставлять доступ соответственно.

Если вы считаете, что веб-ресурс защищен должным образом, вы также можете отойти от базовой восьмеричной системы разрешений и использовать списки контроля доступа:

setfacl -R -m u:www-data:rX my-directory

Это позволяет www-data u SER для доступа к данным и ввести каталоги, начиная с my-directory (-R - то же, что и в chmod , это означает рекурсивное применение изменения.)

Чтобы новые добавленные файлы и папки также имели этот ACL, вы должны установить ACL по умолчанию:

setfacl -R -d -m u:www-data:rX my-directory

Обратите внимание, что ACL должны быть включены как в ядре, так и в точке монтирования. Пожалуйста, обратитесь к руководству файловой системы, которую вы используете для этого. Теперь это значение по умолчанию в большинстве дистрибутивов Linux, поэтому оно может быть уже доступно.

Answer 2

Я думаю, что Списки контроля доступа (из ответа Дэниела Б.) в порядке. Они сильны наверняка. Если вы не можете их использовать, может быть достаточно следующего менее мощного решения:

1. Создайте группу специально для этого случая, например, cl_bob .
2. Затем chown корень документа (рекурсивно) в bob:cl_bob .
3. Добавить пользователей (включая пользователей процессов) в группу cl_bob . Пользовательские www-data должны быть в cl_bob но не в bob ; разработчики, возможно, должны быть в обоих.
4. Включить setgid для каталогов:
   find /clients/bob/document/root -type d -exec chmod g+s "{}" +
   Таким образом, будущие каталоги и созданные в них файлы будут наследовать группу cl_bob независимо от пользователя (процесса), который их создает.
5. Другой пользователь (как в вашем примере cronjob) может быть легко добавлен в группу позже.

Преимущества перед ACL:

• Довольно просто и хорошо известно.
• Легко проверить с помощью стандартных инструментов, таких как ls -l .
• Широко поддерживается из коробки.
• Добавление (удаление) пользователя в группу - это простая операция, которая практически не генерирует дисковый ввод-вывод и не требует времени. Случай может отличаться при рекурсивном применении метаданных ACL.

Недостатки:

• Не такой гибкий. Пользователь, отличный от bob - это xor, которого нет в cl_bob , поэтому разрешения группы xor применяются для других разрешений, tertium non datur. Если вам нужно больше уровней разрешений (например, полное чтение-запись, ограниченное чтение-чтение, отсутствие доступа), вам нужен ACL.
• Общесистемный. Вам нужен root-доступ для создания группы и добавления пользователей в нее; важная информация хранится в /etc/group . ACL намного более приватен, как имя файла; Метаданные ACL хранятся в файловой системе (однако вам все еще нужны /etc/group и /etc/passwd для подключения GID и UID к реальному миру).
• Может генерировать мусор. Представьте, что вы удалили /clients/bob со всем содержимым внутри; группа cl_bob теперь является бесполезным артефактом, если вы не забудете также удалить его. Метаданные ACL удаляются вместе с файлами, мусора не осталось.