Кажется я таки нашёл пресловутый Грааль. :)
Итак, для начала установим пакет inotify-tools, а затем будем использовать inotifywait следующим образом:
inotifywait -mr --format '%w%f' \ -e close_write -e moved_to -e create \ /home/share | while read file; \ do sudo /usr/local/bin/script $file; \ done
Итак, /home/share это общий каталог, при попадании в который, любой файл или каталог должен обрести следующий параметры: принадлежать nobody:users (у меня так, хотя выбор пользователя и группы - дело индивидуальное), /usr/local/bin/script - скрипт, обрабатывающий целевой файл (каталог), следующего содержания:
#!/bin/bash chown nobody.users "$1" if [ -d "$1" ]; then chmod 770 "$1" elif [ -f "$1" ]; then chmod 660 "$1" fi
Собственно, всё. Осталось добавить строку с inotifywait в автозапуск.
Идея использования inotifywait подсмотрена на опеннете, скрипт для обработки взят у Karapuz'а.
Проверено, работает.
Грааль в данном случае это - ACL.
ОтветитьУдалитьМонтируем файловую систему с флагом acl
Проверяем вывод mount:
/dev/sdb1 on /mnt/mybook type ext3 (rw,acl,user_xattr)
Затем создаем общую директорию:
# mkdir share
# chown nobody.users share/
# setfacl -d -m u:nobody:rwx,g:users:rwx share/
Проверим что получилось:
getfacl share/
# file: share
# owner: nobody
# group: users
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:nobody:rwx
default:group::r-x
default:group:users:rwx
default:mask::rwx
default:other::r-x
Теперь все файлы создаваемые в директории share будут принадлежать юзеру nobody и любой юзер из группы users сможет писать и редактировать файлы из этой директории.
Неплохое описание ACL и с чем его едят:
Using ACLs with Fedora Core 2
Проверил. Не работает.
ОтветитьУдалитьTo maxym. ACL справедлив только для новых, ранее ни где не существовавших файлов, повторяю, только для новых. Если файл копировать или перемещать, то права остаются такие же как у исходного файла, то есть тоже копируются или перемещаются. Ни какие ALC'ы и umask'и тут не помогут.
ОтветитьУдалитьTo StraNNicK Я так понимаю, что в этом способе используется инструмент, отличный от fam (gamin), но суть такая же. А в чем преимущество?
ACL заработал, я был неправ.
ОтветитьУдалитьСейчас напишу как это делается.
А я думал: чего-то мне нехватает для каталога с фотками, а оказалось нехватает того чтобы он был общим :)
ОтветитьУдалитьStraNNicK инструкция по ALC будет или
способ maxym и так работает?
Инструкция будет вечером, способ работает, смотри разбирательства в жуйке.
ОтветитьУдалитьVampiRUS, Вышеприведенный способ работает, проверил еще раз только что, но надо сделать еще:
ОтветитьУдалитьchmod 775 share/
так как у обычных прав приоритет выше чем у ACL и сначала обрабатываются они. Подробности во вчерашнем разбирательстве в жуйке у StraNNicK
Даёшь ACL!
товарищи, я что-то из камментов так и не понял, всё же работает способ с ACL для новых файлов или нет? Что за жуйка такая? И вечер 31 числа уже наступил вчера, а инструкции нема ;)
ОтветитьУдалитьЗЫ: Для себя пока решил данную проблему созданием папки с правами рута и монтированием её каждому юзеру в home через bindfs с нужными правами (в моём случае задача усложняется тем что монтироваться она должна в том числе и по сети, а там разные базы пользователей, в результате чего на одном компе с UID 1001 один юзер, на другом - другой или вообще может не быть).
Скажем так - работает, но не с некоторыми ограничениями. Потому - заметки всё же не будет.
ОтветитьУдалитьРазбирательства здесь и здесь (как раз в жуйке).
Если по сети - отчего не smbfs? Оно точно умеет принудительно юзера-группу-атрибуты выставлять.
StraNNicK, smbfs умеет выставлять права на сервере, а мне нужно на клиенте подменять владельца файла на того кому надо, этого я так и не нашёл как там сделать.
ОтветитьУдалитьХмм... А приведённый в _этой_ заметке способ не подходит?
ОтветитьУдалитьПодходит, но насколько я понимаю, он тоже не очень хорошо, т.к. добавляет тормоза в работу всей системы: грузится inotifywait и следит за тем кто что куда пишет, плюс если она вдруг зависнет или вылетит - то перестанет следить.
ОтветитьУдалитьА в моём случае получается что костыли начинают работать и тормозить систему только когда ковыряешься именно в этой папке...
Может конешно я и неправ, но с первого взгляда мне показалось что через bindfs лучше будет...
Unix ACL входит в один из стандартов POSIX. Для его работы должен быть установлен пакет acl и файловая система должна быть смонтирована с опцией acl. Ну и должна её поддерживать :) google:/unix acl linux сильно помогает насчёт тонкостей с маской и т. п.
ОтветитьУдалитьИМХО
Решение с inotify - хтонический квадратноколёсный велосипед.
/ИМХО
Зато работает :)
ОтветитьУдалитьЯ убил три дня на то, чтобы прикрутить ту же функциональность методом ACL. За это время выяснил, что ACL не работает с XFS совсем, а в остальных случаях - при соблюдении некоторых определённых условий.
Поскольку конечная цель - не заморачиваясь получать нужный результат - решение с inotify рулит, педалит и бибикает.
Вот и у меня руки дошли попробовать. Работает на ура, лучше и стабильней gamin. Есть одно дополнение, переменную $file лучше взять в кавычки во избежании игнорирования файлов и каталогов, в именах которых есть пробел.
ОтветитьУдалитьгде-то года два назад читал, что проблему можно решить, если двум различным юзерам присвоить одинаковый UID. Что позволяет иметь два различных хомяка, но при этом одинаковые права для всех файлов(по сути оба юзера будут владельцами).
ОтветитьУдалитьК сожалению не помню деталей, просто стало интересно не копали ли вы в эту сторону?
ИМХО, для домашнего компьютера,где секьюрность не так важна, самое простое решение
Как-то мне этот метод не очень нравится. Уж лучше примерно так.
ОтветитьУдалитьvanuch, использовать метод с bindfs намного лучше, работает прям как надо!
ОтветитьУдалитьА с одинаковым uid мне кажется вылезет больше проблем всяких чем удовольствия.
Ещё одна проблема у меня осталась нерешенной с общим доступом: создание общих папок по сети, может кто чего подскажет?
ОтветитьУдалитьЕсть сервак srv, на нём папка, которая монтируется по nfs на компы comp1 и comp2.
Хотелось бы чтобы в эту папку могли писать пользователи с comp1 и comp2 и на srv было видно где чей файл.
Но проблема в том, что uid на сервере у юзеров один, а на машинах comp1 и comp2 - другой.
Например на srv:
srvadmin1 uid 1001
user1 uid 1002
user2 uid 1003
А на клиентских машинах
comp1 - user1 uid 1001
comp2 - user2 uid 1001
Соответственно, если user2 создаёт файл, то на srv владелец показывается srvadmin1, на comp1 - user1
А если user1 создаёт файл, то на comp2 - владелец видится user2 вместо user1
Поэтому с владельцами файлов на постоянно косяки вылазят всякие. Надеюсь понятно объяснил ;)
Может кто предложит способ решения данной проблемы без создания общей базы пользователей (т.к. это довольно геморно)?
Или может ткнёте ссылкой на статью как попроще сделать общую базу пользователей на компах, чтобы uid соответствовали у всех?
ОтветитьУдалитьА то варианты нашёл только с загрузкой системы на юзерских компах по сети с сервака, но они не очень подходят, т.к. у каждого пользователя свои предпочтения - на сервере debian, у юзеров - ubuntu разных версий, linux mint, ещё всякие разновидности, да и home-папки юзеров хотелось бы не на сервере хранить а на локальных компах, чтобы всякими pron.avi не забивать место на сервере.
А BSD-стиль наследования прав доступа и группы от каталога не пойдёт? Достаточно поставить SUID-бит на каталоге, прописать группу и права доступа к каталогу, и они будут наследоваться всеми подкаталогами и файлами.
ОтветитьУдалитьПроверять лень, но в последний раз, когда я это делал — не сработало.
ОтветитьУдалитьЕМНИП, наследуется только создаваемыми в этом каталоге файлами и подкаталогами, а если скопировать/перенести извне — не наследуется.