Песочницы для пользователей

openvz

Сразу же в голову пришла следующая идея: рут делает снапшот текущей системы (через btrfs), который отдаётся в распоряжение пользователю. Для работы с пакетами используется schroot, для запуска - chroot

можно еще через aufs, но туда / не под монтируешь

Та-же opera умеет ставитьтся в ~/.local если нет root'доступа, может попробовать перенастроиить менеджер пакетов что-бы ставил в ~/.local ?

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

Я думал о подобном (установка в другое место, например, в хомяк пользователя). Не подходит потому, что для работы с пакетами пользователю нужен будет пароль рута.

Ты придумал виртуализацию, молодец.

Можно, но не нужно. Более психозный способ придумать трудно :)

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

Более психозный способ придумать трудно :)

Поясни.

Нужно сделать «песочницу» для пользователя, в которой он смог бы ставить/удалять/обновлять пакеты

Начинание сомнительной полезности для 95% пользователей.
Остальные осилили виртуализацию.

Блин, да что тут пояснять-то? :D Ты предлагаешь поставить тысячи пакетов, чтобы пользователь потыкал их и выбрал с десяток максимум. По мне так это какой-то нездоровый способ.

Я не спрашивал: нужно или нет.

Приведи, допустим, три примера в пользу нужности.

Ставишь все пакеты, запрошенные пользователями, по первому требованию.

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

Даже не подумаю этого делать. Я создал тему для того чтобы люди выкладывали свои идеи по решению моей задачи, а не для того, чтобы оправдываться или защищать её. Если тебе нечего сказать по теме, не пиши сюда больше. Или можешь писать, но отвечать тебе я не стану.

Ну как-бы sudo и op никто не отменял

gentoo prefix?

Ставишь все пакеты, запрошенные пользователями, по первому требованию

Не подходит. У меня нет желания и времени обслуживать желания пользователей.

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

Ну, это волнует меня меньше всего. Свободного места хватает.

Всё-таки sudo это немного не то, что мне хотелось бы. А хотелось бы мне полное невмешательство пользователя в основную систему, но чтобы основная система имела полное вмешательство в пользователя.

Можно как-нибудь по хитрому реализовать через fuse/unionfs.

А обслуживать вместо единой системы семнадцать разных её вариантов желание есть?

Или ты думаешь что таким хитрым способом можно свалить всю ответственность на пользователей и самому больше ничего не делать?

но туда / не под монтируешь

так просто.
Корневой раздел придется 2 раза монтировать. Зато любая fs

А обслуживать вместо единой системы семнадцать разных её вариантов желание есть?

Откуда семнадцать систем? Что творится в пользовательской копии - меня не волнует.

Или ты думаешь что таким хитрым способом можно свалить всю ответственность на пользователей и самому больше ничего не делать?

А то.

И нет расхождения версий.

А вот это и может быть проблемой как раз.

Это делается просто. Приложения устанавливаются в отдельные каталоги типа /usr/pkg/$UUID/$VERSION. Если пользователь захотел установить программу, то если её нет в /usr/pkg, она скачивается и ставится туда. После этого создаются симлинки в /usr/user/$USER. С помощью fs namespaces каталог /usr/user/$USER представляется пользователю как /usr. Когда программу удаляют все пользователи, её каталог в /usr/pkg удаляется.

Тут нужно разрабатывать новую программу. Поэтому предлагаю. 1) Ставишь debian с подключенный бэкпортом. 2) Настраиваешь так что бы каждую неделю происходил автоматический бэкап системных каталогов. 3) настраиваешь через sudo для группы admins (создашь пользователя и группу такую) выполнение через sudo без запроса пароля строки /usr/bin/software-center. На рабочем столе создаёшь значёк запуска sudo /usr/bin/software-center.

Пользователей инструктируешь не лезть в категорию «системные» и ничего не удалять.

Однако вопрос, неужели жалко 15 Гб что бы поставить «всё» ?

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

Если речь о пользователе, плеере и браузере, то пользователь должен тихо молча пользоваться софтом из репозиториев имеющихся версий. А админ должен тихо и мирно ставить необходимый пользователю софт из этих самых стандартных реп с учетом своего списка «доверенных» пакетов, может быть. Так делают, например, тут у нас в универе. И никакого разброда и шатания.

Если речь о разработчике, со своей средой, нужными версиями языков и компиляторов - то это совсем другая песня, там можно разные способы и решения искать в зависимости от задачи.

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

Это огроменная дырища в безопасности

Схренали?

Сборка с префиксом, указывающим на хомяк. Год работал в такой системе. Написал пакетный менеджер, умеющий обновлять произвольный список компьютеров в кластере (это всё было под кластер на Solaris+Linux). Были виртуальные пользователи и SSH с автоматической авторизацией открытым текстом. Единственный минус - на кластере из виртуалок очень тормозное IO и мало проца, т.е. долгая пересборка, тот же GCC мог конпеляться всю ночь. В общем, УМВР.

Xen, KVM. Хотя на поколупатся хватит и OpenVZ, если интересует только колупание пакетов, но не пересборка ядра с пользовательским конфигом.

SSH с автоматической авторизацией открытым текстом.

Нафига? Ключи же есть.

Да, очень просто. Так просто, что нужно написать свой пакетный менеджер.

Можно попробовать так, если клмп достаточно мощный: Xen, в него любой дистрибутив, какой нужен пользователю. Получится такая штука - грузится комп, автоматом стартует хен, в нем дистр, все это сращу растянуть на весь экран, чтоб юзверь не видел того, что под его дистром. Получается, работать он будет как раз в песочнице, основную систему не покоцает, а эту изредка бэкапить целиком.

//Вполне возможно, что уже что-то подобное предлагали, я тред не читал.

Я рассматриваю вариант, который ТС описал в главном посте.

Если речь идет только об установке приложений из реп - то наворачивать вокруг этой простой операции сложную систему нет смысла.

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

Нафига? Ключи же есть.

У кластера был админ. Который не давал ключи, форсил одновременный логин только на 1 машину (когда реально надо было минимум штук 12), тотально запретил SSH-туннели, итп. И пользователей не заводил и другим не давал. О программах можно было даже не заводить речи (по требованию заказчика за 2 месяца установил устаревшую версию емакса, лол). Всё во имя безопасности.

Пришлось сделать «инновационный паразитный дистрибутив». Всё, что не давал админ, у нас было. Разве что кроме пересборки ядра. Самый свежий софт, любые туннели, батчи на группы компов, пользователи с ACLями, итп.

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

Это аргумент из разряда, «зачем нам админ, у нас и так компы хорошо работают».

Если речь идет только об установке приложений из реп - то наворачивать вокруг этой простой операции сложную систему нет смысла.

Т.е. твой вариант решения — поднимать локальный реп и держать там кустомно собранный софт?

делал так у мамки на десктопе )) Только диск с документами - реальная флешка. Когда вирус в очередной раз прибивает ХР, удаленно логинимся и откатываемся на снапшот.

upd: да и все арчи, тащем-то, тоже в виртуалках. Обновлять тестинг, не сделав снапшота - да ну нафиг :)

Мой вариант решения - не отлынивать от работы :) Если уж ты администрируешь компы пользователей - не надо пытаться с помощью странных механизмов свалить с себя ответственность. Потому что в итоге отвечать все равно будешь ты.

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

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

Если речь идет только об установке приложений из реп - то наворачивать вокруг этой простой операции сложную систему нет смысла.

А мне не нужна сложная. Мне нужна простая. Сложную я и сам смог бы накостылять.

Проходи мимо, не отвлекай людей на пустой трёп.

опиши четкие критерии деления пакетов на простые и «непростые»

Причём тут пакеты?

ты пишешь «Имеются в виду всякие прикладные приложения: браузеры, плееры, прочая мелочёвка»

как мелочевка отличается от немелочевки?

Snapper

echo «export PATH=$PATH:/home/`whoami`/usr/bin» >> ~/.bashrc

./configure --prefix=/home/`whoami`/usr/ && make && make install

Кстати сказать, в той же федоре есть малоизученный механизм software collections который насколько я понимаю можно использовать для всякой хитрой установки. Но опять же, это не пользователь должен химичить и ставить что ему в голову взбредет, а админ создает специальным образом сформированный пакет и он же его устанавливает там где нужно.

как мелочевка отличается от немелочевки?

Я же привёл примеры.