Решение немного странное, но жить мона... Хотя порой достает это месиво Х_х

>Вот надо так же хранить конфиги для всех приложений вообще.

спасибо не надо.

Гениальное решение. Это вам не реестр.

>По поводу ~/home/bin, неужели так сложно придумать для своего скрипта уникальное название? Если действительно сложно, то тут явно дело уже не в "/usr/local/bin супротив ~/home/bin".

Замечательно. Домашнее задание: обеспечить безопасность системы, в которой *два* пользователя имеют доступ на запись в /usr/local/bin. Админом ни один не является, отбирать доступ нельзя.

Присоединяюсь к мнению.

> А что тогда мешает в _своём_ $path поставить /usl/local/bin в начало?

Не должно быть юзверских личных скриптов/бинарей в PATH по умолчанию (куда
обычно входит /usr/local/bin). Ни в начале, ни в конце.

> Всё-равно в большинстве дистров он указан после всех или не указан вообще,

Неверно.

> так что системным службам ничего не будет.

Будет, будет. Не верите, пока сами на те же грабли наступите? Ну и б-г с Вами.

> По поводу ~/home/bin, неужели так сложно придумать для своего скрипта
> уникальное название?

1. Создать проблему, а потом ее решать -- глупо.
2. Таки не совсем просто.

> Если действительно сложно,

То ли это мне так везет, а то ли в /usr/bin слишком много всего валяется, но
совпадения случаются не так уж и редко.

> то тут явно дело уже не в "/usr/local/bin супротив ~/home/bin".

Вот закинул я в /usr/local/bin скрипт backup_home. А теперь тоже самое хочет сделать
Вася Пупкин. И что дальше?

> Домашнее задание: обеспечить безопасность системы, в которой *два*
> пользователя имеют доступ на запись в /usr/local/bin.
> Админом ни один не является, отбирать доступ нельзя.

chmod 1775 /usr/local/bin
setfacl -m u:ivanov:rwx /usr/local/bin
setfacl -m u:pupkin:rwx /usr/local/bin

Генитальная находка разработчиков FHS

> конфигурационные файлы .procmailrc, .forward, .less{,key}, .emacsrc, .muttrc, .joerc, .cvspass, .cvsrc, .zshrc, .ssh/* и тысячи прочих

От наглого лгуна слышу.

Не трогаем .emacs и .zshrc, потому что это не конфиги, а скрипты и они остаются как есть. А вот с конфигами... Разумеется, нельзя все загнать в одну структуру, это очевидно, но описать практически любой конфиг (бинарные конфиги sendmail'а лучше похоронить сразу вместе с автором) в рамках графа с достаточно ограниченным набором типов данных нод — никаких проблем нет.

Что, сложно .cvspass представить как список? В венде, Гугль подсказывает, это HKCU\Software\Cvsnt\cvspass.

.procmailrc? Списки условий-регэкспов и действия. Имеем /etc/procmail/$recipe_number/conditions как представление построчно всех условий, /etc/procmail/$recipe_number/conditions/$condition_number (да, файл как каталог, в reiserfs такое есть) как одна строка оттуда, и /etc/procmai/$recipe_number/{action,flags} для действий и флагов. Ничего экстраординарного, все более чем просто. Может что-то забыл, procmail давно заменил на maildrop, если что — прошу простить склерозника.

.ssh/*? Так элементарно, опять же. /etc/ssh/authorized_keys — список, /etc/ssh/id_* — блок текста как он сейчас есть (ну, это неделимо и все в порядке), /etc/ssh/config/$host_name/$option_name — представление опций.

.muttrc? то же самое, словарь опций (set realname=Vasya) и списки (aliases, hooks, ...).

(Смотря в ~/.*) И .rtorrentrc отлично укладывается в концепцию списка опций, и .fetchmailrc, и .htoprc... И .netrc просто представлять, /etc/netrc/$host/$option_name...

И так далее, и так далее, в общем. Лень писать очевидные вещи, которые даже дошкольник, подумав пару минут, расскажет. Если Вы не можете себе этого представить — тренируйтесь на кошках. Конфигов, которые сложно представить в виде орграфа — очень мало, на самом деле. Скрипты, специально повторяюсь, это отдельная вещь. Которую, впрочем, никто не мешает ложить в per-user /etc ровно как сейчас ложим в $HOME.

> Если бы юниковские программы решили, что проще хранить всё в реесте, то давно бы уже появились реестры. (Может они и появились, но никак не в программах, которые использую я.)

А они и появились. Начиная с /proc и /sys. Это не совсем конфиг, конфигурируема там только часть, но представление есть, а этого достаточно. И там униформально представлены достаточно различные вещи.

И в KDE/GNOME оно же есть. Ну да пес с этими монстрами.

И wmii имеет именно такую конфигурацию и очень хорошо живет. Не говоря о Plan9, где это есть, работает и полностью соответствует KISS. А поскольку оно такое — наглым лгуном являетесь именно Вы, а не я. Не согласны — соизвольте ознакомиться с матчастью и потом приходите и говорите что в Плане не KISS. Может быть Вы мне глаза откроете. А может и пукнете в лужицу, как сейчас.

> По поводу ~/home/bin, неужели так сложно придумать для своего скрипта уникальное название?

У меня в ~/home/bin положена экспериментальная версия wmii с моими патчами. System-wide ее ложить нельзя, разумеется — по куче причин, начиная с сырости кода, и заканчивая тем, что патчи специфичны для меня и моих извращенных желаний и другим ненужны(tm). А мне — нужны. И, разумеется, код я постоянно правлю и бинарник желаю обновлять.

Изволите мне у рута (предполагается что это не я) /opt/wmii-with-anonymous-patches/ выпрашивать какой-нибудь? Так это _ничем_ не отличается от ~/bin/.

Нет, клинический случай, это ~/.fvwm/.fvwm2rc (при том, что в .fvwm есть файлы без точки в начале). Хотя, есть подозрение, что это защита от дурака: прежде, чем узнаете, где конфиг, прочитайте man fvwm (полностью :) ).

Насчет .config — согласен, но сама идея с точками мне нравится — куда лучьше атрибута «скрытый».

> К тому же в случае 2 очень сложно (если вообще возможно) написать маску "все такие каталоги", т.к. под очевидное '.*' попадёт и печально известный '..'.

Где? У меня в zsh не попадает ни ".", ни "..". Настройки дефолтные.

>Для любителей ~/.etc:

>export XDG_CONFIG_HOME=$HOME/.etc

Т.е. ВСЕ конфиги будут ложится в $HOME/.etc ???

Дружище, не ложим а кладём. Кроме этого procfs и sysfs работают пока живо ядро, в то время как реестр пока жива fs на которой он лежит, то есть для восстановления реестра после его скропостижной смерти нужно долго танцевать если яйца не помешают - нужна функциональность восстановления после сбоев(см. велосипед). А конфиги .* легко восстанавливаются средствами штатной fs. Плюс разные цели подразумевают разные языки, слыхали в САПР: под каждую задачу язык? Зачем всех под одну гребёнку? Сами же признали наличие проблемы скриптов. Ну и т.д.

Головой думать не пробовали?

> Не трогаем .emacs и .zshrc, потому что это не конфиги, а скрипты 

В *NIX'ах многие конфиги -- это таки скрипты 

> бинарные конфиги sendmail'а лучше похоронить сразу вместе с автором 

Ни разу он не бинарный. sendmail.cf --  это скрипт на snobol.

> .muttrc? то же самое, словарь опций 

Нет. Скрипт.

###---- кусь-кусь-кусь ----

set mbox_type=Maildir

set folder="~/private/mail/`date +%Y`/`date +%m`"
set mask="!^\\.[^.]"
set mbox="~/private/mail/`date +%Y`/`date +%m`/default"
set record="~/private/mail/`date +%Y`/`date +%m`/sent-mail"
set postponed="~/private/mail/`date +%Y`/`date +%m`/drafts"
mailboxes `echo -n "+ "; find ~/private/mail -type d -name ".*" -printf "+'%f' "`

set folder_format=" %N %d %8s %t %f "

send-hook . "set record=~/private/mail/`date +%Y`/`date +%m`/sent-mail"

###---- кусь-кусь-кусь ----


> .ssh/*? Так элементарно, опять же. /etc/ssh/authorized_keys — список, 

Во-первых, аж ни разу он не список. Он подозрительно похож на скрипт:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="rsync --server --daemon --config=$HOME/.rsyncrc ." AABBBCC....

И самое интересное: каким раком sshd должен узнать, как найти ключ[и] юзверя
pupkin? По всем namespace'ам шарить? И Вы всеръез говорите, что это лучше,
чем ~/.ssh?

> /etc/ssh/id_* — блок текста как он сейчас есть 

В /etc/ssh лежат ключи _хоста_, а не юзера. Опять -- смешаем все в кучу,
а потом будем ее разгребать?

> И .rtorrentrc отлично укладывается в концепцию списка опций, и .fetchmailrc, 

Вот такие же "умники" решили, что fonts.conf -- это список, и в результате имеем

<match target="font" >
	 <test compare="less" name="size" >
		 <double>7.0</double>
	 </test>
	 <edit name="antialias" >
		 <bool>false</bool>
	 </edit>
</match>

Ни разу это не список, это программа, и по-человечески ее можно написать так

(add-hook 'antialias-enable-hook (lambda (font) (>= (size font) 7.0)))

> Которую, впрочем, никто не мешает ложить в per-user /etc ровно как сейчас ложим в $HOME.

А ЗАЧЕМ?

> А они и появились. Начиная с /proc и /sys. 

И там же заканчивая. А все потому -- что это "конфиги" ядра. И отдельного
скрипта/файла для его хранения не может быть по определению.

> И wmii имеет именно такую конфигурацию и очень хорошо живет. 

Нету у него конфига. Опять скрипт (на lua).

> И в KDE/GNOME оно же есть. 

Опять мимо:

http://techbase.kde.org/index.php?title=KDE_System_Administration/Configuration
_Files

Советую обратить внимание на параграф "Shell expansion"

> Конфигов, которые сложно представить в виде орграфа — очень мало, на самом деле.

А еще любой конфиг можно записать на brainf-ck'е. Только человеку такое
представление не шибко-то удобно.

> Если Вы не можете себе этого представить — тренируйтесь на кошках. 

Похоже, это именно Вы не представляете последствий.

Точно, хотя в отдельную директорию (.conf) получше бы было.

> То ли это мне так везет, а то ли в /usr/bin слишком много всего валяется, но совпадения случаются не так уж и редко.

Ну у меня мало своих скриптов, ибо обычная домашняя машинка, потому, наверное не сталкивался. Можно начинать их с какого-нибудь префикса, или (о ужс!!!;), пользовать верхний регистр.

> Вот закинул я в /usr/local/bin скрипт backup_home. А теперь тоже самое хочет сделать Вася Пупкин. И что дальше?

Правильный ответ это "запретить доступ и себе и Васе в /usr/local/bin, а свой скрипт перенести в ~/bin?" ;)

> Не должно быть юзверских личных скриптов/бинарей в PATH по умолчанию (куда обычно входит /usr/local/bin). Ни в начале, ни в конце.

Я с тобой целиком и полностью согласен, ты не с тем споришь. ;)

> Замечательно. Домашнее задание: обеспечить безопасность системы, в которой *два* пользователя имеют доступ на запись в /usr/local/bin. Админом ни один не является, отбирать доступ нельзя.

Сам лечи своих сферических коней в лютом вакууме от идеально черной лихорадки.

>Тогда почему бы тебе не убрать его в ~/.config/.bashrc вместе с остальным "мусором" ?

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

>Может потому как он часто меняет его _не_ из гуи, и посему это добавило бы ему ненужной сложности?

+1

>А если у меня валяется временный(е) файл(ы) размером 100 мегабайт и начинающийся с точки ?

OMG! Это что за говнософт? Любая порядочная никсовая прога обязана держать временные файлы в /tmp и /var/tmp, хоть системная, хоть прикладная. А за несоблюдение этого правили надо вырывать, как минимум, руки..

>Или кончающийся на тильдой созданный текстовым редактором временный бекап ?

Причём здесь скрытые файлы? В гуевых фм они отображаются всегда, а в mc показ скрытых и резервных файлов настраивается отдельно. Если это так тебя беспокоит, засунь в cron или стартовые скрипты rm `find ~/ -name '*~'`. А ещё лучше отключить резервные копии там, где они не нужны.

>А если имя файла точно не известно? А если у меня Наутилуса нет, что делать?

Поставить кде. ;) Там и в конке и в диалоге выбора файла при нажатии точки появляется список всех подходящих файлов. А в консоли есть автокомплит.

> Нет. Скрипт.

Гм. Да, здесь я мимо. Соглашусь.

> Во-первых, аж ни разу он не список. Он подозрительно похож на скрипт:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="rsync --server --daemon --config=$HOME/.rsyncrc ." AABBBCC....

Или словарик:

./forwarding/port=false
./forwarding/X11=false
./forwarding/agent=false
./pty=false
./command="rsync ..."
./key=AABBCC...

Проблемы при таком подходе?

> И самое интересное: каким раком sshd должен узнать, как найти ключ[и] юзверя pupkin?

Точно так же как и сейчас. Из root'ового неймспейса оно все остается
так же видно.

> Ни разу это не список, это программа, и по-человечески ее можно написать так
> (add-hook 'antialias-enable-hook (lambda (font) (>= (size font) 7.0)))

Про fonts.conf — полностью соглашусь, потому что сам писал примерно
такую же строчку в каком-то старом флейме про зумельные конфиги.
А вот .rtorrentrc и .fetchmailrc — словари опций. И таких словарей
очень много.

И не всегда нужны скрипты. Скажем, openalrc — конфиг на Схеме, и,
спрашивается, зачем? Чтобы туда «(define devices '(alsa))» запихать?

> И там же заканчивая. А все потому -- что это "конфиги" ядра. И отдельного
> скрипта/файла для его хранения не может быть по определению.

То-то я оно и вижу разбросанным по sysctl.conf, modprobe.d и прочим.

> Нету у него конфига. Опять скрипт (на lua).

Ой ли? У меня там шеллскрипт и архив-образ с начальными настройками.
Lua — это вы с Ion путаете, наверное, вроде там что-то такое.

> http://techbase.kde.org/ ...

И? INI'шки, да. А они это чистое дерево, /$section/$option.

> Советую обратить внимание на параграф "Shell expansion"

И что? Кро мне это запрещает по файлам разложить так же? Написать
не в INI-файл а в файл-опцию?

А вообще спорить смысла мало. Будет когда-нибудь время и желание —
попробую, соберу простенький набросок такой системы  (просто собирать
неймспейсы это не так и сложно, готовые скрипты где-то я видел уже,
а дальше на Python можно FUSE—модулей пописать попробовать, может
все и не особо сложно окажется, или наоборот, увижу что все хуже
чем я думаю) и посмотрю что получится. Или кто-нибудь другой попробует.

На данный момент что все это может существовать я уверен.

Угу. А теперь анонимус пойдёт расскажет авторам всех перечисленных прог, как им надо писать конфиги. В виде словарика опций, скрипта, или программы на Schema :)

>Не должно быть юзверских личных скриптов/бинарей в PATH по умолчанию (куда обычно входит /usr/local/bin). Ни в начале, ни в конце.

Простите, а нафига он тогда вообще нужен?

>Будет, будет.

Примеры?

>То-то я оно и вижу разбросанным по sysctl.conf

sysctl.conf - это конфиг утилиты sysctl, modprobe.d - соответственно modprobe, конфигами самого ядра они не являются.

>А они это чистое дерево, /$section/$option.

Чушь. Каждый файл - это конфиг отдельного приложения/компонента - kickerrc, kdesktoprc, kioslaverc. Никаким "/$section/$option" тут и не пахнет.

>>/usr/local/bin

>Простите, а нафига он тогда вообще нужен?

Например, для программ, которые разработчики дистрибутива ещё не удосужились собрать.

> sysctl.conf - это конфиг утилиты sysctl, modprobe.d - соответственно modprobe, конфигами самого ядра они не являются.

Зато в /{proc,sys} видны.

> Чушь. Каждый файл - это конфиг отдельного приложения/компонента - kickerrc, kdesktoprc, kioslaverc. Никаким "/$section/$option" тут и не пахнет.

Я про отдельный INI говорил. Все вместе — /$application/$section/$option, зануда.

На мой взгляд, выделение отдельной папки под конфиги может привести к тому, что пользователь просто случайно удалит _все_ конфиги разом, а так когда директорий много, все нормально, и случайное удаление одной папки, не повлечет r тому, что пользователь пойдет прыгать с 24 этажа с криком "верните мой .kde!".

Ну и долго этот тупой опрос еще будет висеть?

> На мой взгляд, выделение отдельной папки под конфиги может привести к тому, что пользователь просто случайно удалит _все_ конфиги разом

На мой взгляд выделение отдельного / и отдельного $HOME может привести к тому, что пользователь просто случайно удалит _всю_ систему сразу. Даешь C:\Program Files\, D:\Games, E:\Documents and Settings\ и так далее!

>Например, для программ, которые разработчики дистрибутива ещё не удосужились собрать.

А вот не надо нормальный дистр в Слакварь превращать. ;) В этом случае лучше всего создать собственный пакет, что позволит избежать в будущем многих проблем.

>А вот не надо нормальный дистр в Слакварь превращать.

Вам устраивать свинарник
Не к лицу, любезный сэр.
Не кладите вы бинарник
На просторы ю-эс-эр!

Но, к сожалению, хороший совет зачастую проще дать, чем исполнить.

И потом, если запасное колесо годами лежит в багажнике, это не значит, что оно вообще не нужно.

немного мешают эти катологи. вот если бы в одном всё было, а вообще идея хорошая.

Лучше бы в $HOME структура была bin etc var

сначала создавать проблему в HOME, потом ее решать

> В гуевых фм они отображаются всегда, а в mc показ скрытых и резервных файлов настраивается отдельно.

В мс надо сильно утрудить себя несколькими телодвижениями чтобы включить/выключить.
Или ты предлагаешь пользоватся разными фм с разными настройками ? - кривое решение.

>засунь в cron или стартовые скрипты rm `find ~/ -name '*~'`.

Основная проблема - зачем сначала создавать проблему, устраивая мусорку в HOME, чтобы потом ее доблестно решать ?

Это исторически сложившийся анахронизм, который уже давно пора убрать в ~/.config/* , чтобы не мешал.

> no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="rsync --server --daemon --config=$HOME/.rsyncrc ." AABBBCC....
>
> Или словарик:
> 
> ./forwarding/port=false
> ./forwarding/X11=false
> ./forwarding/agent=false
> ./pty=false
> ./command="rsync ..."
> ./key=AABBCC...
> 
> Проблемы при таком подходе?

Человеку это неудобно редактировать (а конфиг именно для общения человека с
программой предназначен). ФС такого числа файлов не потянут и будут тормозить.
Так зачем же нужны неоправданные усложнения, никак не улучшающие
функциональность?


> > И самое интересное: каким раком sshd должен узнать, как найти ключ[и]
> > юзверя pupkin?

> Точно так же как и сейчас. Из root'ового неймспейса оно все остается
> так же видно.

А зачем тогда огород городить? И еще: как юзверь сможет узнать публичный ключ
хоста? Другого юзера? Сейчас все понятно: в /etc/ssh лежат ключи хоста, в
~/.ssh -- мои ключи, в ~vpupkin/.ssh -- ключи Васи Пупкина. А с этим
unionfs'ом -- один геморрой только.

> И не всегда нужны скрипты. Скажем, openalrc — конфиг на Схеме, и,
> спрашивается, зачем? Чтобы туда «(define devices '(alsa))» запихать?

А может, там не только это можно запихать?

> > Нету у него конфига. Опять скрипт (на lua).

> Ой ли? У меня там шеллскрипт и архив-образ с начальными настройками.
> Lua — это вы с Ion путаете, наверное, вроде там что-то такое.

Не, не путаю.

git clone git://repo.or.cz/wmiirc-lua.git

> И? INI'шки, да. А они это чистое дерево, /$section/$option.

Ага. А любая программа -- это последовательность инструкций для машины
Тьюринга. Срочно переходим на brainfuck?

> И что? Кро мне это запрещает по файлам разложить так же? Написать
> не в INI-файл а в файл-опцию?

Никто. Хотите поиметь проблемы даже там, где их нет -- пожалуйста.

Блин, я только сейчас реально понял, о чем этот опрос, хотя проголосовал 6 дней назад =)

Отличное решение. Не надо лопатить весь реестр, чтобы вычистить/забекапить настройки программы. Просто как всё гениальное :)

>Или ты предлагаешь пользоватся разными фм с разными настройками ?

Я просто пытаюсь понять, к чему ты приплёл бекапы.

>Основная проблема - зачем сначала создавать проблему, устраивая мусорку в HOME, чтобы потом ее доблестно решать ?

А зачем вообще устраивать мусорку? Не проще ли не создавать её или хотя бы автоматизировать удаление?

>Это исторически сложившийся анахронизм, который уже давно пора убрать в ~/.config/* , чтобы не мешал.

А каким образом ~/.config/ поможет решить проблему с временными файлами и бекапами? Те же резервные файлы создаются либо там же, где и оригинал, либо в специально отведённой дире.

Другие уже ответили на твою полнейшую чушь про объединение _принципиально_ необъединимого. Повторяться не буду. Правда никто не ответил на следующее.

> Начиная с /proc

Не верно в корне. /proc вполне себе соизмерим с конфигурациями ~/.[a-z]* и никаким боком реестром не является. Когда хотя бы на этом примере поймёшь свою принципиальную ошибку (в реестре _всё_ типизировано по супер-жёсткой схеме, а в /proc совсем _ничего_ не типизировано, каждый файл имеет свой собственный формат), тогда, думаю, сразу поймёшь и бредовость своей идеи.

А то, что для удобства в /proc имеются поддиректории, так они имеются повсеместно и во всех сложных конфигурациях - где это удобно. Это моё понимание KISS и unix way - добавлять под-директорию лишь там где это удобно, и не добавлять там где это неудобно. Не путать с насильным насаждением громоздких излишних иерархий в реестре просто потому как другого этот неполноценный механизм не позволяет. Вот, скажем, ~/.gimp/ вполне можно сравнить с /proc/ в том смысле, что и поддиректории присутствуют, и формат каждого файла свой собственный, максимально удобный для данного конкретного файла. Или скажем, возьмём fvwm-themes, там кроме повсеместного языка fvwm (например ~/.fvwm/themes/personal/menus-extra) и других типов файлов, есть даже свой мини-реестр для конфигураций (~/.fvwm/themes/current/theme.cfg), но вот ужас - он не совместим с другими реестрами, потому как если в юниксовой программе и есть подобное, то это просто своего рода DSL. Практически прямо противоположное единому системному реестру и тому, что предлагаешь ты.

~/.* – это глобально и надёжно

> скажем нешительное нет архаизму «mount: only root can do that»!

юзеру ничего монтировать не нужно. by design

> Вменяемое -- это… …GUID?

>юзеру ничего монтировать не нужно. by design

Почему?

1) Переносная хрень типа флешей и фотоаппаратов

2) лупбэки (надо только обеспечить проверку прав юзера на этот файл)

3) --bind

4) fuse

>Лучше бы в $HOME структура была bin etc var

сделать какую-то теговую ФС, и будут

>1) Переносная хрень типа флешей и фотоаппаратов

Для переносной хрени уже давно придуман dbus+hal+{ivman|pmount}. И вообще, man fstab на предмет опции user.

>2) лупбэки (надо только обеспечить проверку прав юзера на этот файл)

>3) --bind

>4) fuse

Опция user в /etc/fstab не подойдёт?

>Для переносной хрени уже давно придуман dbus+hal+{ivman|pmount}.

Ладно, согласен. Ещё б сделать чтобы монтировалось в ro а потом перемонтировалось по команде от юзверя... Но это дело настроек.

>Опция user в /etc/fstab не подойдёт?

wget http:...../bolvanka.iso; mkdir ~/cdrom; mount -o loop bolvanka.iso ~/cdrom

Это каким же даром предвидения должен рут обладать, чтобы все это занести в /etc/fstab заблаговременно??

Посмотри как эта комманда и только она разрешается через sudo (/etc/sudoers, man sudoers).

Лично я на своей машине не разрешил бы пользователям из далека монтировать loop. Что не говори, а это тебе не заход в тарбол из mc, когда простым убиванием пользовательского процесса mc возвращаем всё на круги своя, а создание ядром полноценной файловой системы, которую надо потом кому-то размонтировать. Пусть монтируют файлы на собственных машинах, там у каждого нормального владельца должно быть для себя полное разрешение (через sudo; user ALL = NOPASSWD: ALL).