Что нового будет в третьей версии Filesystem Hierarchy Standard?

> дык вроде какие то ФС обладают *изменяемыми* снапшотами - по сути отдельными ветками изменения данных.

Ну, смонтирует оно тебе снапшоты в /zfs/writable_snapshots/*, что ты с ним делать будешь? Смонтируешь в одно дерево и сделаешь chroot? А чем это лучше обычного chroot?

> Тебе что, никогда не приходилось плясать с chroot, bind-ами и установкой пакетов в chroot-системе, чтобы создать какое-нибудь тестовое окружение?

А у меня Debian, детка, и это здорово. :)

kernel 2.6-vserver

newvserver --hostname testing99 --ip 192.168.0.99/24 --dist sid --mirror http://192.168.10.1/debian --interface eth0

vserver testing99 start

vserver testing99 enter

:)

Из пушки по воробьям.

Так это аналог твоей задачи. А для пацанов есть lxc, слышал?

Всё ясно, видимо я не до конца продумал идею переноса /run, о использовании tmpfs даже не подумал.

Всё ясно, видимо я не до конца продумал идею переноса /run, о использовании tmpfs даже не подумал.

>дык вроде какие то ФС обладают *изменяемыми* снапшотами - по сути отдельными ветками изменения данных.

не слышал о таком. Тут скорее дедупликация может помочь.

> Так это аналог твоей задачи.

Это не аналог моей задачи. Это реализация VPS.

> дык вроде какие то ФС обладают *изменяемыми* снапшотами - по сути отдельными ветками изменения данных.

Ну и как это поможет дать разным процессам частично пересекающиеся пространства имён? Никак.

> Это не аналог моей задачи. Это реализация VPS.

Тьфу ты, аналог твоей проблемы с чрутами. Т.е. нет её в дебианах 4.0, 5.0, 6.0. :)

А под аналог твоей задачи lxc разве не подходит?

> lxc

Это уже готовый велосипед, меня интересуют скорее низкоуровневые механизмы. Чтобы собрать свой собственный велосипед с квадра^W^W.

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

Нашел описание, как SE Linux делает перекрытие /tmp для разных пользователей: http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html Точно так же можно переопределить /usr, например.

Стало быть, механизмы для задачи в линукс есть, кто б только пакетник писать взялся. :D

>XDG_CONFIG_HOME (и остальное, что там ещё есть), вот этого вот хватает.
А где в этом прекрасном XDG должны лежать сокеты, к примеру?

>нахрена вообще бинарники толкать в хомяк пользователя?
С той же целью, что и мелкие скрипты.

Подскажите пожалуйста, где можно на русском более-менее подробно почитать про FHS?
Я в этих /bin /usr/bin /usr/local/bin уже совсем заблудился.

В википедии.

Есть не пушка. man schroot.

Зачем бинарник пихать в хомяк пользователя? А если я (пользователь) хочу поставить программу, то я должен бегать за админом? и это многопользовательская система?

Сокеты в идеале вообще не должны «лежать». Какой больной сказал, что сокет это файл? Для программы пусть имеет fd, но зачем он в файловой системе? так же как и содержимое run - кому реально нужны эти пиды. Если бы сделали нормальный способ программе заблокироваться от повторного запуска или найти свои экземпляры, это все можно было бы вообще выкинуть.

А если для поднятия /var нужно udev или вообще сеть? А для сети допустим dhcpd, а ему надо создать файлик в /var/run...

> А если я (пользователь) хочу поставить программу

man NixOS

то я должен бегать за админом? и это многопользовательская система?

Ты, как пользователь, сможешь делать только то, что админ разрешил. Да, и именно поэтому _это_ — многопользовательская система. В отличие от винды.

>Ты, как пользователь, сможешь делать только то, что админ разрешил

Бредовая концепция. Каждому пользователю можно бы выделять отдельную песочницу, и пусть он туда ставит, что хочет.

Каждому пользователю можно бы выделять отдельную песочницу, и пусть он туда ставит, что хочет.

В том числе SMTP open relay, и HTTP и SOCKS-прокси для свободного доступа во внутреннюю сеть снаружи. Правильно. Так держать.

И иметь по надцать копий одних и тех же программ? Фееричненько.

А зачем те же программы дублировать полностью?

> > Зачем бинарник пихать в хомяк пользователя? А если я (пользователь) хочу поставить программу, то я должен бегать за админом? и это многопользовательская система?

> А зачем те же программы дублировать полностью?

Вы уж между собой определитесь. :D

Всё просто. Если юзер хочет ставить уже имеющуюся в системе программу, её можно отобразить в хомяк с помощью тех же линков. Если хочет ставить что-то новое, то происходит полноценная установка пакета.

конфиги не лежат в пакетах. Только темплиты конфигов.

Еще немного, и ты поймешь. :D Вот правильный вариант:

Пользователь имеет отдельное пространство имен для ПО. У админа есть белый список пакетов, которые разрешены для использования пользователями. Пользователь ставит пакет в своё пространство имен полностью под контролем пакетного менеджера. Установка сводится к проверке, присутствует ли уже пакет в локальном хранилище и его скачивании и распаковке по необходимости, а затем — размещению всех нужных симлинков в пространстве имён.

А мне сказали в нашем лор-отделе

Ну вот отлично, ты и защитишь :)

Не распарсил.

>Для программы пусть имеет fd, но зачем он в файловой системе
А как mpc найдёт нужный экземпляр mpd? Или cmus-remote будет искать cmus.
Меня больше интересует, что делать с уже имеющимся софтом. Сокеты — не конфиги, в ~/.config им делать нечего. В /tmp и /var/tmp их может удалить произвольный юзер. А XDG-филы почему-то аггрятся на ~/.app_name.

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

В ненавистных виндах есть отдельные неймспейсы для ядерных объектов (всяких пайпов, сокетов, устройств, мутексов), а кроме того мне нравится идея оконных сообщений, передача которых стоит столько же сколько вызов функции. Если уж очень хочется сохранить концепцию «все есть файл», то можно бы сделать где-нибудь директориюу ..../kernel_objects и в ней уже sockets, processes...

...А ведь ее уже придумали, и называется она /proc, только разместить в ней сокеты никто не додумался.

Для этого в юниксах придумали «привилегированные порты», все которые меньше 1024. Еще одна дырявая идея безопасности, да. Вообще, запрет ставить программы в хомяк не мешает при наличии перла/питона запускать из хомяка smtp relay или proxy написанные на том же перле. Так что если уж безопасности все равно нету, можно сделать чтобы было удобно.

А если программу поставили два пользователя? А если ее потом поставит админ? отладка этого будет адским адом. Хотя идея хорошая, да. Но между тем что есть сейчас в линуксе ( необходимость раздачи судо) и тем что есть в винде (всякие хромы, квипы и прочее ставится в ~/appdata) я выбираю винду.

>...А ведь ее уже придумали, и называется она /proc, только разместить в ней сокеты никто не додумался.
Оно опять же не per-user. Можно сделать per-user namespaces через PAM, но ни один известный мне дистрибутив по дефолту этого не делает.

В ненавистных виндах есть отдельные неймспейсы для ядерных объектов

Я как бы в курсе.

>В /tmp и /var/tmp их может удалить произвольный юзер
Брежу, там +t.

> А если программу поставили два пользователя? А если ее потом поставит админ?

Не вижу никакой проблемы в этом. Видимое, не понял вопроса. Объясни, что ты имеешь ввиду.

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

В NixOS? Запускается suid-программа, которая проверяет права пользователя на установку ПО и выполняет все требуемые действия.

Multi-user support

Starting at version 0.11, Nix has multi-user support. This means that non-privileged users can securely install software. Each user can have a different profile, a set of packages in the Nix store that appear in the user’s PATH. If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.

В ненавистных виндах есть отдельные неймспейсы для ядерных объектов (всяких пайпов, сокетов, устройств, мутексов),

Это не решает проблему, а переносит её на другой уровень.

а кроме того мне нравится идея оконных сообщений

Внезапно, в иксах тоже есть ICC.

Если уж очень хочется сохранить концепцию «все есть файл», то можно бы сделать где-нибудь директориюу ..../kernel_objects и в ней уже sockets, processes...

...А ведь ее уже придумали, и называется она /proc, только разместить в ней сокеты никто не додумался.

Это всё не про то. Нужно место в пространстве имён, где будут размещаться средства IPC, локальные для данной учетки: сокеты, пайпы, точки монтирования вспомогательных файловых систем FUSE. Такого места нет ни в линуксе, ни, тем более, в винде.

Сейчас в хомяке размещать такие файлы логически не верно, т.к. хомяк это данные пользователя. Имхо, следует пересмотреть само отношение к директории $HOME и стандартизировать её подкаталоги как часть FHS. Например, $HOME/etc — для конфигов, $HOME/run для сокетов, точек монтирования и т.п., $HOME/files — уже непосредственно для основных файлов пользователя.

> /proc, только разместить в ней сокеты никто не додумался.

Ты ничего не понимаешь в устройстве ОС.

я выбираю винду.

Хорошо бы еще, чтобы ты просто забыл о существовании Linux.

> объясните мне , нахрен вам несколько версий одной и той же софтины?

Со школоло не разговариваем. Вырастешь - приходи обсуждать.

То она должна ставиться общесистемно или для каждого юзера отдельно?

Про опасность багов в suid программах рассказывать надо? Посмотрел что такое nixos... Надо попробовать захерачить на этом сервер, возможность откатов мне понравилась. А всякие конфиги и прочее там где хранятся?

Такой путь меня точно не устраивает:

/nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config

А либы там шаред или у каждого пакета свой набор получается?

Тогда не для учетки, а для сессии. Предположим я залогинен в систему с нескольких точек входа (vnc, ssh, локально...) Часть таких объектов должна относиться к сессии (типа сокетов и пайпов), а другая - к пользователю (типа точек монтирования). В винде опять же обмен между программами одной сессии идеально ложится на оконные сообщения.

btw, ICC гуглится только как профили цвета, видимо не очень популярная технология.

Помимо хомяка, надо еще решить проблему общих хранилищ, типа фильмов и музыки, в FHS это совсем никак не предусмотрено, многим проще сделать nas или усб винт, чем разбираться с этим.

чуть модифицирую то что тут уже говорили: проги распологаются так

/programs/${progname}${version}/[bin,etc,share,..., home]

линки в соответствии с текущей иерархией (можно пакетным менеджером)

/etc/${progname} -> /programs/${progname}${version}/etc

/bin/${progname} -> /programs/${progname}${version}/bin

...

прога должна работать по макс в своей песочнице : /programs/${progname}${version}/ это и про конфиги и про подгружаемые данные...

но надо только механизм обеспечивающий для каждого пользователя /programs/${progname}${version}/home -> /home/${user}/program/${progname}${version} /programs/${progname}${version}/tmp -> /home/${user}/tmp/${progname}

в принципе symlink (~/program/${progname}${version} или ~/tmp/${progname}${version}) подойдёт

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

> Со школоло не разговариваем. Вырастешь - приходи обсуждать.

То есть, обосновать не можешь. Слив засчитан.

> То она должна ставиться общесистемно или для каждого юзера отдельно?

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

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

> Про опасность багов в suid программах рассказывать надо?

Б-же, у тебя в системе будет 2 программы с suid — su и интерфейс к пакетнику. Ну хорошо, три — если еще sudo используешь. В трех небольших программах баги-то уж выловить сообщество осилит, не?

А всякие конфиги и прочее там где хранятся?

А хз, я уже не помню подробностей. Читай ман. Я побежал по делам.

> Часть таких объектов должна относиться к сессии (типа сокетов и пайпов), а другая - к пользователю (типа точек монтирования).

Да. Это тоже неплохо бы предусмотреть.

btw, ICC гуглится только как профили цвета, видимо не очень популярная технология.

Inter-Client Communication же.