[plan9][linux] Зачем в /proc/ pid/ есть mounts

AFAIR да, есть разные пространства имен для монтирования.
Вроде как chroot на это завязан.

А от пользователя я могу смонтировать ФС в каталог так, чтобы это было видно только текущему процессу и его потомкам (как в plan9)?

Ну насчет произвольного пользователя не уверен.
А так чтобы тольно одному процессу - тот же chroot.
Ему передаешь комманду и рут фолдер. А там монтируешь что угодно.

Впринципе наглядный пример, в choot зачастую proc
монтируют, для удобства.

Кроме chroot это еще гду-то используется?
Кстати в файле нетолько корень указан, а вообще все смонтированные ФС.

Не скажу точно где еще используется, но по части остальных
смонтированных фс: подумай сам, еслия флэшку или партицию в
chroot-е смонтирую она должна одинаково видеться процессами
в chroot-е и вне choot-а?

Меня интересует возможность процессам пользователя видеть разные пространства имен.

Например, примонтировать одну директорию поверх другой только для текущего процесса и его потомков, при этом без прав суперпользователя (или через какой либо suid-ный специальный mount) возможно?

Я думаю тебе стоит прочитать ссылку.
http://www.kernel.org/doc/man-pages/online/pages/man2/chroot.2.html

Only a privileged process (Linux: one with the CAP_SYS_CHROOT
capability) may
call chroot().

A child process created via fork(2) inherits its parent's root directory. The
root directory is left unchanged by execve(2).

P.S. Ей богу, маны рулят и они компетентнее меня.

> Вроде как chroot на это завязан.

Блин, chroot НИФИГА на это не завязан. Совешенно разные вещи используемые совместно.

Гугли namespace mount linux. Там статья на ibm.com например

Upd : ксатате с разморозкой - эта фича появилась в 2.4.19 ;):):)

Статью я кажется нагуглил http://www.ibm.com/developerworks/linux/library/l-mount-namespaces.html
Но того про что я писал там нету...
Похоже, что так нельзя.

Вообще заинтересовало меня это вот по какой причине:
Бакап директорий, типа как TimeMachine от яблоков.
Собственно с бакапом все понятно.... некий сервис копирует изменившиеся файлы.

Заковырка с «полетом во времени». Есть, например директория mydir, сервис делает снапшоты, штук десять уже наделал...
Теперь надо посмотреть что там было в прошлом.
Для процессов которым надо прошлое содержимое нужного снапшота монтируется поверх mydir, остальные процессы продолжают видеть настоящее состояние.

Получается супер-пупер:
- пути к файлам не меняются
- проги переписывать не надо
- можно работать из командной строки

Для этого надо:
- Возможность приватного монтирования, чтобы монтирование было видно только процессу, который его произвел и его потомкам.
(Почитал, погуглил, может это и можно, надо вникнуть)
- Чтобы все это делалось без рутовых прав.

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

Если нужно монтироварие от юзера, то скорее всего копать в сторону
fuse. Но монтирование поверх не поможет с уже открытыми файлами AFAIK.
Можно посмотреть в сторону fuse и версионной fs. Это кажется мне более
адекватным чем копирования.

Копирование или версионная ФС - уровнем ниже.
В любом случае содержимое снапшота (хоть из ФС, хоть просто копию) надо показать пользователю.
Можно показать просто в другом месте типа /backup/2010-02-23_18:20/mydir/subdir, но это не так удобно.
А можно этот /backup/2010-02-23_18:20/mydir/subdir наложить поверх mydir/subdir для файлового менеджера и программ, которые он будет запускать.
Как-то так...

Можно вообще много чего. Например взять OpenSolaris с TimeSlider
и не прариться. Или набрать в гугле TimeMachine Linux и взять
один из уже готовых костылей.

Solaris - это solaris, круто, но я не хочу, думаю, что многие не особо торопятся переходить на него.

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

> Вы хотите сказасть что команда chroot не использует системный вызов

chroot?

Я хочу сказать что команда chroot никак не использует системный вызовы для работы с namespaces. И наоборот namespaces не используют системные вызовы chroot.

Посему столь яростные возгласы несколько не понятны.

Вы написали "... есть разные пространства имен для монтирования.Вроде как chroot на это завязан.". Что является бредом.

> - Чтобы все это делалось без рутовых прав.

Вот без рутовых прав не получится, а с ними(ограниченными) это как раз возможно. Кстати в современных десктопных линусах это решено. Для таких задач как ваша и был придуман PolicyKit.

То есть можно написать такую программу которая будет делать что вы хотите и оно будет работать на современных десктопных линуксах.

Для командной строки утилита для namespaces(не помню названия, вроде vnamespace)+fuse+утилита на dbus для работы с PolicyKit. Вся эта связка должна создать неймспейс, запустить в нем bash, потом подмонтировать туда ваш бэкап через fuse. Ну или sudo настроки для конкретной утилиты. В убунте это даже в пакет закатывается штатно.

Ссылку или объяснение как работает chroot.

Вопрос снят.

А PolicyKit точно мне поможет? Ведь на момент, когда надо подмонтировать бакап процесс, которому надо его монтировать (файловый менеджер) уже есть.

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

PolicyKit assumes a model where a program is split into two parts. One part, the Mechanism, runs privileged (with no user interface elements) and the other part, the policy agent, runs unprivileged. The two parts of the program are in different processes and communicate through some IPC mechanism such as pipes or the system message bus (D-Bus). In some instances the Mechanism can be considered part of the core OS and the policy agent part of the desktop stack.

Что то не похоже, что это то что надо...

> А PolicyKit точно мне поможет?? Ведь на момент, когда надо

подмонтировать бакап процесс, которому надо его монтировать

(файловый менеджер) уже есть.

В такой постановке задачи вам ничего не поможет :)

Т.е. я в ФМ открыл директорию (для которой выполняется бакап), в ФМе

есть временная шкала. Я щелкаю на шкале и при этом должно происходить

монтирование нужного бакапа.

Но процесс уже запущен и без рутовых прав.

У вас в голове неправильная архитектура приложения которая вообще не ложится по человечески на юникс. В юникс все «наследуется». Тут нет волшебных палочек - взмахнул и запушенное приложение ВДРУГ поимело все права. Процесс либо их имел и потерял, либо имеет, либо не будет им иметь никогда.

Вам нужно этот ФМ специальным образом запускать, что бы кнопка работала. Можно запускать не в режиме «смотреть бекап», но важно чтобы ФМ был запущен в отдельном неймспейсе. Ну или запускать некий агент для FM который будет выполнять команды от его имени(например примитивный ftp сервер на локальном порту и коннектится к нему через стандартный FM, они сейчас вроде все умеют). Но тогда никакие монтирования не нужны ;)

По этому выход реально простой один - запускать отдельный FM в отельном namespace и творить им что угодно. А копировать уже из него в нормальный, через какую нибудь промежуточную директорию.

В общем юзер-экпириенс можно любой получить, но у вас не в том направлении мозг работает.

У меня он работает в направлении стройной концепции (как мне кажется), т.е. чтобы это было не костылями как сейчас (да и как в МакОС) а полностью прозрачно для приложений.
Я думал, что у процессов могут быть приватные пространства имен (думал так потому, что увидел список монтированных ФС у каждого процесса) без необходимости в привилегиях (как, например в plan9), но к сожалению ошибся.
Похоже, что так сделать не получится.