Ответы:
В зависимости от того, чего вы хотите достичь, могут быть разные способы сделать эту работу (или, по крайней мере, дать хакерское подобие нужной вам функциональности).
Установка программного обеспечения во многом сводится к тому, чтобы сделать ресурсы доступными или разрешить доступ к вещам, которые уже присутствуют в системе.
Независимо от того, говорите ли вы о предоставлении доступа к принтерам или разрешаете пользователю выполнять программы в определенном каталоге, есть способы сделать это, и, хотя они могут быть встроены в Ubuntu, решения такого типа обычно (конечно) собираются быть добавлен после факта установки .deb.
Вот два основных класса контроля после установки, которые можно добавить. Обратите внимание, что при наличии правильной среды, например, при наличии жестко контролируемой групповой политики, это может быть проще, если у вас есть базовая система. Такие разрешения могут быть даже привязаны к LDAP или аналогичной системе, которая может предоставлять аутентификацию и авторизацию для каждого пользователя или группы.
Контроль видимости
У меня была, возможно, несколько похожая ситуация, но в моем случае пользователи были (пока) не очень искушенными (всем им было меньше 7 лет). Для меня просто скрывать меню Gnome и / или удалять настольные программы запуска.
Удаление исполняемого бита из каталогов исключает возможность процессов искать или проходить по ним. Он может эффективно сделать их невидимыми, а с точки зрения пользователя - сделать их недоступными. Если у вас есть системная политика по умолчанию, которая создает меню, например, на основе доступа к файлам, вы можете использовать этот вид косметического решения, а затем запустить его для последующих установок без особых дополнительных усилий.
Контроль выполнения Контроль ресурса может осуществляться через разрешения Unix, профили apparmor, разрешения SELinux и так далее. В зависимости от приложения могут присутствовать другие уровни фильтрации управления. В отсутствие более целенаправленных решений вам, возможно, придется написать обертки вокруг определенных программ для контроля доступа пользователей или процессов.
Ну, dpkg
это вам не поможет, так как это не является его целью. Он хочет быть единственной переписью пакетов, установленных в системе.
Единственное, что приходит на ум, - это просто извлечь пакет и попытаться поместить файлы вручную в домашнюю директорию.
Однако это будет работать только для некоторых вещей. Множество пакетов разбиты на куски (исполняемые файлы или скрипты в /usr/bin
, библиотеки в /lib
и другие вещи /usr/share
и т. Д.), И эти места жестко запрограммированы скриптами сборки. Таким образом, если вы попытаетесь втянуть нечто подобное в это ~
, оно сломается. Вы могли бы часами разматывать зависимости, но вы могли бы сделать что-то полезное в свое время, например, найти лекарство от рака или впитать в себя часть красоты в мире.
Вы бы сделали намного лучше, просто взяв не упакованную версию у того, кто пишет программное обеспечение. Почти все свободное программное обеспечение доступно в виде сжатого архива в виде исходного кода, так что хватайте его и просто создавайте. Вы не делаете make install
шаг. Ваше приложение создано, просто поместите его туда, куда хотите.
/etc/init
, ищет файлы конфигурации /etc
или имеет некоторые другие пути в жестком коде.
./configure --prefix=$HOME/local
.
Я не слишком разбираюсь в этом вопросе, но из других ответов видно, что вы можете установить пакет в другой каталог вместо /
с dpkg
помощью --root
параметра, а затем выполнить chroot
команду dir, которой был пакет " установлен "в (который, конечно, может быть каталогом в домашнем каталоге пользователя).
Чтобы установить пакет для пользователя, отличного от root
, может быть возможно использовать вышеуказанный процесс с fakechroot
вместо chroot
.
Отказ от ответственности : Я не пробовал это, и не имеют большого опыта работы на момент написания с dpkg
или chroot
, но от того, что я действительно знаю об этих инструментах, этот процесс только может работать.
Ссылки, содержащие информацию, которая может быть полезна для людей, которые хотят достичь эффекта chroot
без root
возможностей:
chroot
fakechroot
)Теперь я немного поработал над тем, что касается этой темы, и выяснил еще кое-что ...
Фрагменты (строительные блоки местной среды):
chroot(1)
Полная (полная локальная среда провайдеров):
chroot(1)
, mount --bind
, binfmt_misc
и работают бинарные программы из других архитектур , используя для QEMU пользовательского пространстваОписание : эмулируя или фактически имея локальные привилегии root, пакеты DEB могут быть установлены для локальной среды.
Вы, вероятно, можете использовать --root
опцию dpkg
установки в другой каталог. Но, вероятно, возникнут проблемы, если приложение будет искать вещи в фиксированных местах, например /etc
.
Короче говоря, я не думаю, что есть легкий путь.
Вы можете изменить владельца исполняемого файла так, чтобы только один пользователь мог запустить его. Затем, при необходимости, вы можете удалить приложение из меню других пользователей.
~/bin
. В этом вопросе есть двусмысленность относительно того, хочет ли Takkat ограничить доступ / видимость многопользовательского приложения, или он хочет установить однопользовательское приложение. Ваши вопросы и вопросы аранжировки используют первое толкование, а остальные предполагают второе.
Сомнительно.
Дебы - это в основном архивы, которые извлекаются в корень вашей файловой системы при установке (плюс некоторые настройки). Если вы хотите установить их только для одного пользователя, вам нужно как-то установить их в папку / home / user. Даже если вы это сделаете, они не будут работать, так как двоичные файлы приложения не будут помещаться в / usr / bin (или что-то подобное), и система не найдет их, если вы попытаетесь их запустить. Точно так же библиотеки и т. Д. Были бы бесполезны, так как система не знала бы, что они находятся где-то в / home. Вы можете попробовать подход грубой силы и настроить переменную PATH так, чтобы она указывала, куда вы извлекли файлы из архива deb, но это будет не только ОЧЕНЬ небезопасно, но может привести к проблемам с совместимостью (например, пункты меню не будут работать, поскольку GNOME расширяет файлы .desktop в / usr / share / Applications).
Более того, если вы установили пакет только для некоторых пользователей, это может вызвать сумасшедшие проблемы с зависимостями, если любой другой установленный пользователем пакет конфликтует с другим, который вы установили только для себя - и, возможно, появятся тонны других проблем, связанных с управлением пакетами.
Все эти проблемы чрезвычайно затрудняют управление пакетами для пользователей по отдельности, поэтому кажется, что невозможно установить их только для одного пользователя, потому что идея, лежащая в основе .debs, не позволяет этого сделать.