Заставить владельца на созданные файлы и папки

У меня есть каталог, который содержит данные, которыми обмениваются несколько пользователей. Доступ к этому каталогу и всем, что находится под ним, будет контролироваться группой каталога, которая будет добавлена ​​к соответствующим пользователям. В качестве такового я создал chmod g+sнабор папок «Sticky Group» . Каталог будет содержать древовидную структуру с каталогами и файлами, с общим количеством файлов, вероятно, несколько миллионов. Файлы будут довольно маленькими, я не ожидаю ничего больше, чем 50 МБ.

Моя проблема в том, что владельцем файла или каталога по-прежнему является пользователь, который их создал. Таким образом, даже если бы я удалил этого пользователя из группы доступа, я бы не удалил его доступ полностью.

Так:

Есть ли другие варианты, которые я пропустил, чтобы гарантировать, что все файлы и подкаталоги имеют одного и того же владельца?

Я ожидаю, что смогу периодически просматривать весь каталог с помощью cron-job, но это кажется мне неэффективным для того, что по сути является командой Once-pr-file.

Я нашел пример с использованием INotify, но мне кажется, что он требует большого обслуживания, поскольку требует сценариев.

Я не смог выяснить, может ли ACL помочь мне с принудительным владением.

Есть ли более умный способ сделать это?

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

Установка владельца по умолчанию «автоматически» потребует, чтобы каталог setuidвел себя как setgid. Однако, хотя это можно настроить во FreeBSD, другие системы UNIX и Linux просто игнорируют u+s. В вашем случае, однако, может быть другое решение.

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

Итак, по сути, из того, что я вижу, вы хотите контролировать доступ к каталогу, используя механизм групп. Однако для этого не требуется ограничивать разрешения во всей структуре каталогов. На самом деле, --xбит выполнения каталога может быть именно тем, что вам нужно. Позвольте привести пример. При условии, что...

• Группа, контролирующая доступ к group_dirкаталогу, есть ourgroup.
• Только люди в ourgroupгруппе могут получить доступ group_dir.
• user1и user2принадлежат ourgroup.
• Маска по умолчанию - 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--разрешение на сам файл).

Однако в этом случае есть небольшая проблема: из-за типичного umask элементы, созданные пользователями, не могут манипулироваться другими членами группы. Вот где приходят 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 по умолчанию, настроенные на то же самое, что и их parent ( /var/grpdir), и, конечно, имеют исполняемые биты, установленные для пользователя и группы. Если вы удалите пользователя из sharingгруппы, он не сможет получить доступ к каталогу (ни к каким файлам в нем, даже если они им принадлежат).

В отличие от периодического исправления разрешений с помощью cronjob, разрешения всегда синхронизируются, так как они обновляются атомарно с помощью вновь созданных файлов и каталогов. Это решение легкое; никаких демонов не требуется, и нет никакого всплеска ввода-вывода при исправлении разрешений одним махом.

Я не знаю ни одного хорошего способа сделать это. Технически самым чистым способом была бы файловая система FUSE, которая делает это. Конечно, много работы, если никто еще этого не сделал.

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

1. Используйте самбу. Самба имеет force userпараметр. Вы можете экспортировать каталог локально и смонтировать его локально. Не делает доступ быстрее, но может быть приемлемым, так как задействована только обратная связь.

2. Используйте не Linux-файловую систему, такую ​​как FAT32. Это должно быть настроено для определенного пользователя, чтобы монтировать его. Права доступа должны обрабатываться родительским каталогом.

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

В этом случае, я думаю, что ваша лучшая ставка - это работа cron с флагом chown -R, как упоминал Pandya. Положите его на крон для запуска каждую минуту или каждые пять минут.

Если вы можете объяснить, как ваши пользователи используют это, может быть, есть лучшее решение.

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

Вы можете использовать inotify-tools и написать простой скрипт bash, как показано ниже. Inotify будет следить за сетью каталогов и делать что-то, когда в веб-каталоге будет происходить событие, такое как создание директории. Есть много событий, существующих. Вы можете погуглить или посмотреть на этом сайте

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