Примушування власника до створених файлів і папок

У мене є каталог, який містить дані, якими можна ділитися між кількома користувачами. Доступ до цього каталогу та нічого, що знаходиться під ним, контролюватиме група директорій, яка буде додана до відповідних користувачів. Як такий я створив chmod g+sнабір "липкої групи" . Каталог буде містити структуру дерева з каталогами та файлами, загальна кількість файлів, ймовірно, становить кілька мільйонів. Файлів буде досить мало, я не передбачаю нічого більшого, ніж 50 Мб.

Моя проблема полягає в тому, що власник файла або каталогу все ще є користувачем, який його створив. Таким чином, навіть якщо я повинен видалити цього користувача з групи доступу, я не видалив би його доступ повністю.

Так:

Чи є інші варіанти, які я пропустив, щоб гарантувати, що всі файли та підкаталоги мають одного власника?

Я вважаю, що можу періодично переглядати весь каталог із завданням cron, але це вражає мене як неефективного для того, що є по суті командою один раз-pr-file.

Я знайшов приклад за допомогою INotify, але це вражає мене як високий рівень обслуговування, оскільки він вимагає сценаріїв.

Я не зміг зрозуміти, чи може ACL допомогти мені у примусовій власності.

Чи є розумніший спосіб це зробити?

Мені хочеться мати каталог, яким можна поділитися, додавши групу до користувача. Все, що створено в цьому каталозі, успадковує схему дозволів від свого батьківського. Якщо є кращий спосіб, ніж те, що я намагаюся, я всі вуха.

Якщо встановити власника за замовчуванням "автоматично", потрібен каталог, який setuidби поводився так setgid. Однак, хоча це може бути налаштовано на FreeBSD, інші системи UNIX та Linux просто ігнорують u+s. Однак у вашому випадку може бути інше рішення.

Мені хочеться мати каталог, яким можна поділитися, додавши групу до користувача. Все, що створено в цьому каталозі, успадковує схему дозволів від свого батьківського. Якщо є кращий спосіб, ніж те, що я намагаюся, я всі вуха.

Отже, в основному, з того, що я бачу, ви хочете контролювати доступ до каталогу за допомогою механізму груп. Однак це не вимагає обмеження дозволів у всій структурі каталогу. Насправді --xбіт виконання каталогу може бути саме тим, що вам потрібно. Дозвольте навести приклад. Якщо припустити, що ...

• Група, що контролює доступ до group_dirкаталогу, є ourgroup.
• Лише люди в ourgroupгрупі можуть отримати доступ group_dir.
• user1і user2належать ourgroup.
• Типова umask - 0022.

... врахуйте наступні настройки:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Тут, припустимо, кожен предмет створив його власник.}

Тепер у цій установці:

• Усі каталоги можуть вільно переглядати всі користувачі ourgroup. Будь-хто з групи може створювати, переміщувати, видаляти файли в будь-якому місці group_dir(але не глибше).
• Той, хто не ourgroupвходить, буде заблокований group_dir, і тому не зможе маніпулювати чим-небудь під ним. Наприклад, user3(хто не є членом ourgroup), не може читати group_dir/user2_submission/README(навіть якщо він має r--дозвіл на сам файл).

Однак у цьому випадку є невелика проблема: через типовий умаск елементи, створені користувачами, не можуть маніпулювати іншими членами групи. Тут надходять ACL-адреси. Встановивши дозволи за замовчуванням, ви переконаєтесь, що все добре, незважаючи на значення umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Цей набір викликів:

• rw(x)Дозволи для власника за замовчуванням .
• rw(x)Дозволи для групи за замовчуванням .
• Немає дозволів для інших. Зауважте, що оскільки інші не мають доступу до них group_dir, це не має особливого значення, які їхні права нижче.

Тепер, якщо я створю елемент як user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Якщо цей ACL на місці, ми можемо спробувати відновити попередню структуру:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Тут знову кожен елемент створює його власник.}

Крім того, якщо ви хочете дати трохи більше енергії / безпеки тим, хто використовує каталог, ви можете розглянути питання про клейкість. Наприклад, це не дозволить user1видалити user2_submission(оскільки він має -w-дозвіл на group_dir):

$ chmod +t group_dir/

Тепер, якщо user1спробує видалити user2каталог, він отримає прекрасний Operation not permitted. Зауважте, що, хоча це запобігає змінам структури каталогів group_dir, файли та каталоги під нею все ще доступні:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Інша річ, яку слід врахувати, - це те, що ACL, які ми використовували, встановлювали дозволи за замовчуванням . Тому власник предмета може змінювати пов’язані з ним дозволи. Наприклад, user2може ідеально працювати ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... отже, зробить його повний каталог подання недоступним для всіх у групі.

Однак, оскільки ви спочатку готові надати повний rwsдоступ будь-кому з групи, я припускаю, що ви довіряєте цим користувачам, і що ви не очікуєте від них занадто багато шкідливих операцій.

Існує розумніший спосіб зробити це. Він використовує поєднання set-gid та acls за замовчуванням . Очевидно, вам знадобиться файлова система з включеним acl. Давайте припустимо, що каталог, за яким ви хочете поділитися, є, /var/grpdirі що члени групи sharingповинні мати доступ до нього.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

ACL за замовчуванням успадковуються підкаталогами, створеними в каталозі з ACL за замовчуванням. Отже, це означає, що будь-який файл, створений у /var/grpdir, матиме свою групу, встановлену sharingбітом setgid каталогу. Крім того, він успадковуватиме acls за замовчуванням, що замінить стандартні передумови стилю Linux, оскільки ми не визначали ACL з конкретними користувачами чи групами. Це означає, що всі файли будуть створені з правом власності <user>:sharingта дозволами rw-rw----. Каталоги будуть однаковими, за винятком того, що вони також матимуть власні ACL-адреси за замовчуванням, встановлені таким самим, як і їхній батьківський ( /var/grpdir), і, звичайно, мають виконувані біти, встановлені для користувача та групи. Якщо ви видалите користувача з sharingгрупи, він не зможе отримати доступ до каталогу (ні до яких-небудь файлів у ньому, навіть якщо він є ним).

На відміну від періодичного виправлення дозволів за допомогою cronjob, дозволи завжди синхронізовані, оскільки вони оновлюються атомним чином за допомогою новостворених файлів та каталогів. Цей розчин легкий; ніякі демони не потрібні, і під час виправлення дозволів одним махом не існує шипу до IO, виправляючи дозволи.

Я не знаю жодного доброго способу зробити це. Технічно найчистішим способом була б файлова система FUSE, яка це робить. Звичайно, багато роботи, якщо ніхто ще цього не зробив.

Альтернативи:

1. Використовуйте самбу. force userПараметр samba має . Ви можете експортувати каталог локально та монтувати його локально. Не робить доступ швидшим, але може бути прийнятним, оскільки бере участь лише мережа зворотного циклу.

2. Використовуйте файлову систему, яка не є Linux, на зразок FAT32. Це має бути налаштовано для певного користувача, щоб змонтувати його. Дозволами доступу повинен керуватися батьківський каталог.

Я не чув жодного способу автоматичної зміни власності на файли таким чином, що власник файлу змінюється при переміщенні файлу в певний каталог. Найближче - це клейкий біт, але, здається, ви вказали, що право власності на групу недостатньо, фактична власність користувача повинна змінитися.

У такому випадку, я думаю, найкраща ваша ставка - це робота із кроном із прапором chown -R, як згадував Пандія. Покладіть його на крон, щоб бігати щохвилини чи кожні п’ять хвилин.

Якщо ви можете пояснити, як ваші користувачі користуються цим, можливо, буде краще рішення.

ACL може допомогти вам отримати більш точний контроль зерна щодо того, хто може робити, це не буде автоматично змінювати фактичне право власності на файл для вас. Я думаю, що вам потрібно отримати більш високий погляд і оцінити / переробити рішення на цій основі.

Ви можете використовувати inotify-інструменти та написати простий скрипт bash, як показано нижче. Inotify буде стежити за веб- каталогами та робити щось, коли в веб-каталозі відбудеться така подія, як створення dir . Існує багато подій. Ви можете його google або можуть подивитися на цьому веб-сайті

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done