Общий каталог на Linux десктопе

Представим ситуацию, на домашнем компьютере установлен Linux. Данным компьютером пользуетесь Вы и Ваша жена. Для этого в системе создано два пользователя, у каждого свои настройки почтовика, свои закладки, свой WM и наконец свои обои. Вроде бы все хорошо и все всех устраивает, но вот есть некий контент, свойственный для десктопа, для которого необходимо организовать общий и главное полный доступ для обоих пользователей. Что тут можно сделать? В голову сразу приходят несколько решений:

1. Установить для общего каталога соответствующий umask;
2. Установить соответствующий default acl;
3. Установить бит SGID.

Хорошо, применили одно из решений, или все сразу. Вроде все работает. Оба пользователя имеют полный доступ ко всему содержимому общего каталога, новый файлы в этом каталоге наследуют его права, но вот Вы скинули в этот каталог фотографии с фотоаппарата. В систему под своим пользователем заходит Ваша жена и решает немного изменить эти фотографии, только вот при сохранении появляется сообщение о недостаточных правах. Оказывается скопированные Вами файлы не наследовали права общего каталога. Почему? Да потому, что утилите cp пофигу на Ваши umask'и и acl'ы. Она копирует файлы с сохранением исходных прав, либо права уменьшаются, все зависит от прав на каталог, куда копируем.

В этой статье я предложу свой способ решения данной проблемы. Нет, способ не красивый и не изящный, потому, вместе с описанием способа, предлагаю Хабрасообществу обсудить этот вопрос и предложить свои решения для организации общего каталога на Linux десктопе.

Необходимые инструменты


Этих инструментов всего два:
1) fam или gamin — сервис мониторинга файловой системы. Что использовать, выбирать Вам, но я рекомендую gamin, потому как fam сам по себе устарел, да и gamin работает стабильней.
2) fileschanged — маленькая консольная утилита, которая по сути является клиентской программой fam или gamin.

Пример использования


Пусть наш подопытный каталог будет ~/Фото. Все действия будем проводить с ним.
Для начала нам нужно создать скрипт/usr/local/bin/script следующего содержания

#!/bin/bash
if [ -d "$2" ]; then
chmod 774 "$2"
elif [ -f "$2" ]; then
chmod 664 "$2"
fi


Этот скрипт будет изменять права на все новые элементы в каталоге ~/Фото. Для файлов rw-rw-r--, для каталогов rwxrwxr-x. Если используете fam, не забудьте запустить fam daemon

/etc/rc.d/fam start

Теперь при помощи fileschanged нужно этот скрипт выполнить.

fileschanged -cCfr -x /usr/local/bin/script ~/Фото &

Вот собственно и все. Теперь fileschsnged будет слушать что говорит fam (gamin) по поводу изменений в каталоге ~/Фото и ко всему новому применять скрипт/usr/local/bin/script.

А как Вы организуете общий каталог?

Написано по мотивам статьи из моего блога

UPD: Еще одно решение подсказал khim. Суть заключается в следующем:
1. Оба пользователя должны быть в разных первичных группах. Так вроде сделано у RedHat. При создании нового пользователя создается одноименная группа.
2. Создаем для обоих пользователей группу family (например).
3. Владельцем общего каталога делаем группу family и устанавливаем права на него 2775.
4. Для gnome, запускаем gconf-editor и в разделе /system/storage/default_options/vfat устанавливаем umask 002. Это значит, что на всех монтируемых устройствах с ФС fat права на файлы будут 664. Как это сделать в kde пока не могу сказать, нет его под рукой.
5. Теперь смело копируем контент в общий каталог. Владельцем этого контента станет группа family (унаследует от каталога), а права останутся 664.
PS. Первый пункт для того, чтобы скопированные файлы с носителя fat в личный каталог были доступны только Вам.
PSS. Все это хорошо, но как быть с CD. Там файлы только для чтнения и umask установить не получиться.
+28
19 июля 2009, 15:31
38
karapuz 9,1

комментарии (78)

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
0
karapuz #
В том-то и дело, что для копируемых файлов не работает.
Вот смотрите. Имеем файл 22 с правами rw-r--r-- Далее последовательность действий
mkdir ~/Desktop/1
chmod g+rwx 1
umask 002
cd ~/Desktop/1

Проверяем
umask
0002

touch 1
cp 22 ~/Desktop/1

Опять проверяем
ls -l
-rw-rw-r-- 1 jura users 0 Июл 19 22:49 1
-rw-r--r-- 1 jura users 2 Июл 19 22:49 22

Как видно для для файла 22 права не изменились. Umask справедлив для новых файлов. Тоже самое при установке default acl.
НЛО прилетело и опубликовало эту надпись здесь
+2
karapuz #
Не выход, не скажу же я жене: «Ты вот когда скопируешь фотки, не забудь открыть вот это черное окно и...». Это десктоп, тут в ходу GUI.
НЛО прилетело и опубликовало эту надпись здесь
0
kyb27 #
Чтобы сохранить права нужно копировать вот таким крокодилом
tar cf — что-то | ( cd куда-то; tar xvf -)
Здесь другой вопрос уместен — меняют ли файловые манагеры права как ср?
НЛО прилетело и опубликовало эту надпись здесь
+1
gribozavr #
Что не так с cp -ax?
0
kyb27 #
есть не везде.
0
GHS #
cp -p пробовали?
0
prodd #
опция -p вообщето служить для сохранения исходных параметров файла, чтобы можно было их сохранить, если установка владельца или группы приводит к ошибке, suid и sgid
биты сбрасываются.
и в данном случае она совершенно не поможет так как изначально не было прав на запись для группы
0
GHS #
Ну а если их добавить? Тогда права группы должны сохраниться или нет?
0
prodd #
оригинал karapuz:
Не выход, не скажу же я жене: «Ты вот когда скопируешь фотки, не забудь открыть вот это черное окно и...». Это десктоп, тут в ходу GUI.

вам же сказали кто будет вручную менять права на запись группе после копирования фото с фотоаппарата? а если они были выставлены то cp можно использовать и без всяких опций
0
GHS #
В $HOME/.profile обоих пользователей прописать umask 012. В итоге будут права на запись группы для обоих пользователей не?
0
prodd #
по идее да
+1
GHS #
попробуйте в $HOME/.profile обоих пользователей прописать umask 012. В итоге у Вас по умолчанию файлы будут создавать с полным доступом для группы, потом копируйте cp -p.
–1
Kindigo #
эээ… у меня примоунтенный раздел диска в fat (по необходимости). в чём проблема?))
+2
karapuz #
А у меня есть некоторое количество DVD iso размером более 4 ГГб. Проблема в ограничении fat на размер файла (4 ГГб).
–27
Azy #
И это потом мне будут грить что линукс — дружественный к пользователям. Убейте меня кто-нибудь.
0
mikes #
не стоит тут начинать холивары и разбрасыватся такими словами.
у каждой системы есть свои недостатки и достоинства
0
adontz #
Речь идёт не о недостатках, а об архитектурных ошибках. Самая-Неправильная-ОС при копировании файла устанавливает для него права доступа конечной папки, а при перемещении сохраняет исходные. Причём какие именно правила доступа конечной папки будут распространяться на новые файлы тоже можно указать. Это логично и не вызывает дурацких проблем у пользователей.
0
mikes #
согласен что права доступа в ntfs организованы лучше чем в ext3/4 но топик не про это в общем то
0
xxxYURAxxx #
вы забыли про права на файлы и папки в fat32
так чт оне надо холиваров
+3
zanudische #
У FAT32 прав на файлы и папки нет. То есть вообще. Атрибуты readonly/hidden/system не считаются, т.к. никак не защищены от изменения.
Права доступа есть у NTFS, причем развесистые и избыточные чуть более, чем полностью (в т.ч. там легко можно задавать взаимоисключающие сочетания правей). Зато у NTFS есть фича «дочерние каталоги/файлы наследуют права от предков», чего в линуксовых ext2/3/4 иногда не хватает.
+4
onk #
есть наследование
вот только когда кидаешь файлы в расшаренную папку с такими правами, приходится делать сброс аттрибутов для новых файлов. практически всегда.
может быть зависит от файлового менеджера (любил я пользоваться фаром на винде)…

тут просто вопрос в том откуда система растет.
линукс вырос из юниксовых систем. и по дефолту использует политику запретить все. а если пользователю надо чтото отдать другому — изменит права
в винде скорее наоборот — сначала раздаем всем, а затем уже прячем особо ценное…
(не говоря уже о дефолтном пользователе «администратор» в XP)

так уж исторически сложилось
0
Marsikus #
Убьем обязательно. Я сам хоть и виндовозец, но Линукс очень уважаю и иногда пользуюсь некоторыми его преимуществами.
+3
stolen #
Можно извратиться и смонтировать NFS локально. У nfsd есть замечательная опция squashall, которая любое обращение к ФС на стороне клиента транслирует в обращение на стороне сервера строго под одним юзером.
Возможно, такая же фича присуща локальным папкам, только мне об этом неизвестно.
0
cblp #
Наверное, можно аналогичный трюк провернуть чрез FUSE.
+2
cblp #
Действительно, можно — code.google.com/p/bindfs/
0
karapuz #
Вот это тоже интересно, дома обязательно попробую, спасибо.
–6
odessky #
Мужа и Жену добавить в группу Семья
Дать на шару полные права для группы Семья

Вопросы?
0
karapuz #
И давать эти права постоянно ручками для всего нового, что попадет в этот каталог? Нужен полный доступ для всего контента, в том числе и для нового.
–3
baxtep2 #
перекомпилить cp из исходников, изменив исходный код, так что бы файлы в месте назначения получали права каталога…
+2
develop7 #
Евгений Ваганович, залогиньтесь.
+1
GloooM #
Можно поступить по другому, расшарить и смонтировать хоть самбу хоть nfs локально себе на комп с соответствующими правами.
+2
stolen #
Чуть выше я предлагал, но, как оказалось, есть более корректный метод на основе FUSE.
0
alexxz #
А чем не подходит использовать bsdgroups при монтировании и umask 0002? Останется только включить нужных пользователей в нужную группу.
0
vk2 #
Вероятно, тем, что можно работать не только с mountpoints, но и с произвольными каталогами?
0
vk2 #
Проще говоря, мы решаем вопрос автматически установки g+w в sgid-каталоге вне зависимости от исходной umask. Логично.
–12
Zagrebelion #
Надо сохранить этот пост и показывать всем, кто радеет за линукс на десктопах.
+1
vasilisc #
я добился нужного! (эксперимент делал на папках моего проекта связанного с 1С, так что сорри, аналогию с Семьей сами проведите)
для общей папки права можно создать так
chmod 2770 bases2
$ls -laF
drwxrws--- 4 vasilisc 1c 4096 2009-07-20 10:59 bases2

в группе 1с пользователи vasilisc и tu1
vasilisc@vasilisc:/1c$ grep 1c /etc/group
1c:x:1001:vasilisc,tu1,tu2

под пользователем tu1 запускаю Xorg скриптом так (мне пока так удобно!)
#!/bin/sh
umask 0002
startx — :1
exit 0

и если tu1 создаст в bases2 файл в файловом проводнике Наутилус, то файл родится с нужными правами
смотрим!
vasilisc@vasilisc:/1c/bases2$ ls -laF test5gui.txt
-rw-rw-r-- 1 tu1 1c 0 2009-07-20 10:58 test5gui.txt

то есть смысл остался такой! нужно делать umask 0002 перед стартом X пользователям и все!
+3
karapuz #
Да это все понятно, все это справедливо для создаваемых файлов, то есть новых, ранее ни где не существующих. А вот если копировать уже существующий, права не меняются.
+1
kmmbvnr #
Поставил в плюс в карму.

Такие терпение и объяснения всем очевидных вещей в каментах нельзя не отметить.
0
vasilisc #
и не нужно! главное что остается возможность редактировать и сохранять результаты
какая разница что файл принадлежит вашей жене, если общая ваша группа «семья» позволяет вам редактировать файлы жены и vice versa
0
karapuz #
Скопируйте файл с правами rw-r--r-- в ваш каталог bases2 и посмотрите что будет.
0
vasilisc #
да вы правы! в попыхах не проверил этот вариант
так хотелось быстрее похвастать =)
+3
vk2 #
но слушайте, Вы уверены, что везде хотите создавать файлы с таким umask? он же не будет ограничен одним каталогом…
+1
loginex #
есть куча способов:
1)держать нфс или фтп локально
2)смонтировать директорию в маунтпоинт для каждого юзера с определенным умаск
3)в крон зафигачить cmod 664 -R на директорию с общими файлами(не рекомендую, так как не люблю лишние процессы, особенно если они к диску обращаются)
4)использовать фат32 раздел, смонтированный с определенными правами
5)… думаю можно очень долго придумывать и дальше
0
kmmbvnr #
>> cmod 664 -R
Слишком долго, на достаточно больших файлопомойках
0
Sap_ru #
FTP и NFS плохо дружат с множеством маленьких фалов — тормоза будут жуткие даже при работе в пределах одной машины. Не говоря о том, что это путь через зад. Тоже самое и раздел FAT32 — ограничение на размер файла, плюс потеря владельца файла и всей информации о правах, плюс необходимость деражать ещё один раздел сомнительного назначения. Крон бедт работаь медленно и грустно набольшом количестве файлов, плюс регулярно совершать дурную работу. Остаётся только монтирование, но там тоже сад граблей.
Интересно, а если ACL включить, то получится как в винде через наследование атрибутов сделать?
0
karapuz #
Нет, не получится, пробовал. Новые файлы получают нужные права, а вот скопированные нет.
0
loginex #
остается то, что больше и лучше подходит под потребности.
лично я держу отдельный раздел под файлы. Сомнительное значение? У этого решения очень много плюсов: во первых случайнопереполненный раздел не повредит работу системы и программ, которые пишут разные файлы в /var и /tmp. Во вторых бекапить систему можно удобно отдельно от общих файлов, создавая сжатый образ разделов системы. Ну… в третьих… если есть виндовз на том же ПК, то очень удобно будет работать с этими же файлами из под него.
+1
AlexcYeCu #
А назначить двух именованых пользователей для каталога в home и кинуть ссылку на каталог на десктопы пользователей не судьба?
Нафига весь этот огород городить?
Напоминает анекдот про «2*2» и студентов с разных курсов…
+1
kitsune00 #
поясните свою идею примером, плз
0
AlexcYeCu #
В смысле? Зписать видео, как я добавляю именованного пользователя для папки? В kde это скрывается за кнопкой «дополнительные права». Где это в остальныех DE/WM, я не интересовался. Работает, ясное дело, для всех файловых менеджеров и утилит.
0
kitsune00 #
есть универсальный интерфейс командной строки)

habrahabr.ru/blogs/linux/64868/#comment_1809111

хотелось бы видеть права на файлы в подобном случае

ну и скриншот бы не помешал, а то в этом GUI пока разберешься…
0
karapuz #
Речь идет об acl (man getfacl, man setfacl). Чтобы увидеть эти настройки в gui, нужно в опциях монтирования раздела в fstab прописать «acl» (без кавычек).
Теперь для создателя данной ветки обсуждения, почитайте созданную мной когда-то ветку на форуме opennet.ru.
+1
Ravennick #
Думаю решение очень хорошее. остается вопрос: а сколько fam кушает ресурсов?
0
karapuz #
Используйте gamin, он не демон :)
0
goletsa #
Эм. Мне почемуто приходит в голову создание отдельной группы и назначение прав типа 774
Т.е. все кто вписаны в группу имеют туда полный доступ на чтение и запись.
–1
goletsa #
Вроде какойто бит при копировании заменял владельца и\или группу на нужную
Надо будет ща маны почитать
0
goletsa #
Вариант Группа + права 774 + cron заменяющий права пока выглядят проще всего ;)
0
Sap_ru #
Ага, а когда общей папке накопится стопицот файлов, крон будет регулярно соврешать много дурной работы. И вообще он будет много дурной работы регулярно совершать.
0
vk2 #
«какойто бит»…

Вы бы статью прочитали сначала.
0
TiGR #
А смонтировать общую папку отдельным разделом, с nosuid?
0
4orever #
Подскажите, как это сделать.
0
Iskin #
С помощью acl можно выставить umask на папку, который будет слушаться и cp. Но лично не проверял и нетт нужной команды :( — помню, что вопрос такой задавали в LinuxFormat.
0
torkve #
Есть уже упоминаемый ACL.
И когда-то для расшаривания данных от имени пользователя ftp я делал просто запись в fstab с опцией bind:
/home/user/Music /var/ftp/anonymous/Music ext3 bind,uid=117,ro 0 0

Таким образом, мы монтируем каталог, принадлежащий user, в другую папку и как каталог, принадлежащий ftp (для этого и указываем uid=117).
ro — это уже необязательная опция, исключительно в целях безопасности.
+1
4orever #
Вроде бы выше писали, что для скопированных файлов это не работает (только для новых).
+2
4orever #
Буквально вчера меня мучал этот вопрос. В голову пришло монтирование папки аля bind, но не нашел, как реализовать. В комментариях пишут про bindfs — отлично работает, спасибо!
И спасибо, что подняли эту тему — одной нерешнной проблемой меньше :)

P.S. Для себя настроил просто (У меня есть общая папка, в которую коллега из винды по SMB обращается. Я к ней имею локальный доступ, монтировать NFS или SMB не хотелось):
1. Создаем группу общих пользователей.
2. Монтируем нужный каталог в другой со следующими параметарми:
bindfs -g shared_group -p g+w,g+r,o-r,o-w,o-x source_dir dest_dir

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

0
lasc #
повесить крон, пусть раз в минуту права фиксит )
0
anthonio #
А я доверяю своей жене. У меня в системе пользователь. :)
0
anthonio #
*в системе пользователь один.
0
dema #
У такого варианта есть недостатки — рабочий стол, закладки, открытые окна и история в браузере… Да и вообще все настройки всех приложений.
0
karapuz #
Да о каком доверии Вы говорите, все намного банальней. «Мне не нравятся твои обои, давай поставим лучше эти, да и вообще, что ты тут понастраивал, вчера все по другому было...»
+1
nobu #
Большое спасибо, очень помогла ваша статья :)

У нас была проблема с правами для доступа к GIT-репозиторию через SSH: после коммита одного пользователя, другой не мог изменить файлы, созданные первым (т.е. сделать свой коммит).

Долго искал, как такое решить, в итоге ваш способ помог ^^
Also, если кто знает, как это решить «стандартно» и напишет, буду очень благодарен :)
0
Murz #
Ещё один вариант решения данной проблемы: leolik.blogspot.com/2010/07/bindfs.html
Имхо более правильный чем описанный в статье

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.