Під час встановлення програм через програмний центр або через файл DEB вони, як правило, встановлюються системно для всіх користувачів.

Чи існує спосіб встановити додаток лише для одного користувача?

Залежно від того, що ви хочете виконати, можуть бути різні способи зробити цю роботу (або принаймні надати шалений вигляд потрібної функціональності).

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

Якщо ви говорите про надання доступу до принтерів або дозволити користувачеві виконувати програми в певному каталозі, існують способи цього досягти, і хоча вони можуть бути рідними для Ubuntu, такі рішення зазвичай (звичайно) збираються буде додано після встановлення .deb.

Ось два загальні класи керування після встановлення, які можна додати. Зауважте, що, враховуючи правильне середовище, наприклад, коли діє чітко контрольована групова політика, це може бути простішим після створення базової системи. Цей вид дозволу може бути навіть прив’язаний до LDAP або подібної системи, яка може дати аутентифікацію та авторизацію для кожного користувача або групи.

Контроль візуальності
У мене була, можливо, дещо схожа ситуація, але в моєму випадку користувачі не були (ще) не дуже складними (всім їм було менше 7 років). Для мене спрацьовувало лише приховування меню Gnome та видалення пускових систем на робочому столі.

Видалення виконуваного біта з каталогів виключає можливість процесів їх пошуку або обходу. Це може ефективно зробити їх невидимими, а для користувачів - зробити їх недоступними. Якщо у вас є системна політика за замовчуванням, яка створює меню на основі доступу до файлів, наприклад, ви можете отримати таке косметичне рішення на місці, а потім змусити його працювати для наступних установок з невеликими додатковими зусиллями.

Контроль виконання Контроль над ресурсом можна здійснювати за допомогою дозволів Unix, профілів apparmor, дозволів SELinux тощо. Можливо, існують інші рівні фільтрації керування, які можуть вступати в гру залежно від програми. За відсутності більш націлених рішень, вам, можливо, доведеться писати обгортки навколо певних програм, щоб контролювати доступ користувача або процесу.

Ну dpkgне допоможе вам, оскільки це не його мета дизайну. Він хоче бути єдиним переписом пакетів пакетів, встановлених у системі.

Єдине, що вам спадає на думку, - це просто витягнути пакет і спробувати розмістити файли вручну в домашньому режимі.

Однак це буде працювати лише для деяких речей. Багато пакунків розбиваються на шматки (виконувані файли або сценарії /usr/bin, бібліотеки в /libта інше вбрання /usr/shareтощо), і ці місця жорстко кодуються сценаріями складання. Таким чином, якщо ви спробуєте втягнути щось подібне ~, воно зламається. Ви можете витратити години на розмотування залежностей, але можете зробити щось корисне зі своїм часом, наприклад, знайти ліки від раку або поглинати частину краси у світі.

Ви б краще зробити просто взяти непакетовану версію від того, хто пише програмне забезпечення. Практично все безкоштовне програмне забезпечення доступне в якомусь стисненому архіві як джерело, тому захопіть це та просто побудуйте його. Ви не зробите make installкроку. Ваш додаток побудовано, просто покладіть його там, де ви хочете.

Я не дуже багато знаю про цю тему, але мені здається , з інших відповідей , які ви можете встановити пакет в інший каталог замість /з dpkg, використовуючи --rootпараметр, а потім зробити chrootв директорію якої пакет був " встановлено "в (що, звичайно, може бути dir у домашній директорії користувача).

Щоб встановити пакет для іншого користувача root, можливо, можна використовувати вищезазначений процес, fakechrootа не chroot.

Відмова від відповідальності : Я не пробував це, і не мають великого досвіду роботи на момент написання з dpkgабо chroot, але від того, що я дійсно знаю про ці інструменти, цей процес тільки може працювати.

Посилання, які містять інформацію, яка може бути корисною людям, які хочуть досягти ефекту chrootбез rootможливостей:

• Ця сторінка про кріплення кріплення лише для читання (здається, що це може бути корисно навіть людям, які роблять "стандарт"chroot
• Ця сторінка на сервері defaultfault.com
• Ці сторінки про Linux Containers
• Сторінка людини дляfakechroot )

Оновлення

Зараз я трохи попрацював з речами, які стосуються цієї теми, і дізнався ще дещо ...

Фрагменти (локальні будівельні блоки):

• Fakechroot - емулюєchroot(1)
• Debootstrap - Створіть іншу ієрархію файлової системи Debian всередині каталогу
• Fakeroot-NG / fakeroot - може прикидатися коренем для деяких речей
• EmDebian - варіант debian, який використовує менше місця та часто використовується в середовищі chroot
• binfmt_misc - може запускати файли, використовуючи їх інтерпретаторів, як ніби вони є рідними бінарними файлами; корисно разом з користувачем qemu для роботи з бінарними файлами (або в (підробленому) chroot) зарубіжних архітектур ( скрипти / qemu-binfmt-conf.sh, який постачається з вихідним кодом QEMU, це автоматизує)
• Користувацький простір Qemu - може запускати бінарні файли інших архітектур; можна використовувати з деякими з цих інструментів, коли вони не підтримують деякі архітектури процесора
• LwIP - мережевий стек TCP / IP, який можна запустити з простору користувача

Повний (повний локальний постачальник довкілля):

• Користувальницький режим linux - запускає іншу систему Linux як звичайний процес / програму
• Qemu - запустіть повний віртуальний комп'ютер
• PRoot - забезпечує функціональні можливості chroot(1), mount --bind, binfmt_miscі працюють бінарні програми з інших архітектур , використовуючи для QEMU просторів перед
• Простори імен Linux - Дозволяє мати повний корінь у локальному середовищі при використанні просторів імен користувачів - функція, доступна у версії ядра Linux версії 3.8 та пізніше.

Короткий зміст : Емулюючи або фактично маючи кореневі привілеї локально, пакети DEB можуть бути встановлені для локального середовища.

Можливо, ви можете скористатися --rootопцією dpkgінсталяції в інший каталог. Але, ймовірно, виникнуть проблеми, якщо програма шукатиме речі у фіксованих місцях /etc.

Якщо коротко, я не думаю, що існує простий шлях.

Ви можете змінити право власності на виконуваний файл, щоб лише один користувач міг запустити його. Потім, якщо потрібно, ви можете видалити програму з меню інших користувачів.

Сумнівні.

Деб - це в основному архіви, які під час встановлення витягуються до кореня вашої файлової системи (плюс деякі конфігурації). Якщо ви хотіли встановити їх лише для одного користувача, вам потрібно було б якось встановити їх у папку / home / user. Навіть якщо ви зробили це, вони не працюватимуть, оскільки бінарні програми fe не приземляться в / usr / bin (або що-небудь подібне), і система їх не знайде, якщо ви спробуєте запустити їх. Аналогічно, бібліотеки тощо були б марними, оскільки система не знала, що є десь у / home. Ви можете спробувати підхід грубої сили та налаштувати змінну PATH, щоб вказувати, куди ви витягли файли з архіву deb, але це було б не тільки ДУЖЕ небезпечно, але це може спричинити проблеми із сумісністю (записи меню fe не працюватимуть, оскільки GNOME розширює .desktop файли в / usr / share / застосунках).

Більше того, якщо ви встановили пакунок лише для деяких користувачів, це може спричинити шалені проблеми залежностей, якщо будь-який інший встановлений користувачем пакет, що конфліктує з іншим, який ви встановили лише для себе, - і, можливо, з'явиться багато інших проблем, пов'язаних з управлінням пакетом.

Усі ці неприємності вкрай важко керувати пакетами окремо для користувачів, тому, здається, встановити їх неможливо лише для одного користувача, оскільки ідея, що стоїть за .debs, це відключає.