Podczas instalowania aplikacji za pośrednictwem centrum oprogramowania lub pliku DEB zwykle instaluje się je w systemie dla wszystkich użytkowników.

Czy istnieje sposób na zainstalowanie aplikacji tylko dla jednego użytkownika?

W zależności od tego, co chcesz osiągnąć, mogą istnieć różne sposoby, aby to zadziałać (lub przynajmniej dać złudzone pozory pożądanej funkcjonalności).

Instalacja oprogramowania na wiele sposobów sprowadza się do udostępnienia zasobów lub umożliwienia dostępu do rzeczy, które są już obecne w systemie.

Niezależnie od tego, czy mówisz o przyznaniu dostępu do drukarek, czy też o pozwoleniu użytkownikowi na uruchamianie programów w określonym katalogu, istnieją sposoby na osiągnięcie tego i chociaż mogą one być rodzime dla Ubuntu, tego rodzaju rozwiązania na ogół (oczywiście) zostać dodane po instalacji .deb.

Oto dwie ogólne klasy kontroli poinstalacyjnej, które można dodać. Zauważ, że biorąc pod uwagę odpowiednie środowisko, np. Gdy ściśle kontrolowana jest polityka grupowa, może to być łatwiejsze, gdy masz podstawowy system. Tego rodzaju uprawnienia można nawet powiązać z LDAP lub podobnym systemem, który może udzielać uwierzytelnienia i autoryzacji dla użytkownika lub grupy.

Kontrola widoczności
Miałem chyba nieco podobną sytuację, ale w moim przypadku użytkownicy nie byli (jeszcze) bardzo wyrafinowani (wszyscy mają mniej niż 7 lat). Dla mnie wystarczyło ukrywanie menu Gnome i usuwanie programów uruchamiających pulpity.

Usunięcie bitu wykonywalnego z katalogów eliminuje możliwość przeszukiwania lub przechodzenia przez procesy. Może skutecznie sprawić, że będą niewidoczne, a pod względem użytkownika - niedostępne. Jeśli masz na przykład domyślne zasady systemowe, które tworzą menu oparte na dostępie do plików, możesz zastosować tego rodzaju kosmetyczne rozwiązanie, a następnie sprawić, by działało przy kolejnych instalacjach przy niewielkim dodatkowym wysiłku.

Kontrola wykonania
Kontrolę zasobu można wykonać poprzez uprawnienia Unix, profile apparmor, uprawnienia SELinux i tak dalej. Mogą istnieć inne poziomy filtrowania kontroli, które mogą mieć zastosowanie w zależności od aplikacji. W przypadku braku bardziej ukierunkowanych rozwiązań może być konieczne napisanie opakowań wokół niektórych programów w celu kontrolowania dostępu użytkownika lub procesu.

Cóż dpkg, nie pomoże ci, ponieważ nie jest to jego celem projektowym. Chce być wyłącznym spisem pakietów root zainstalowanym w systemie.

Jedyne, co przychodzi mi na myśl, to rozpakowanie pakietu i próba ręcznego umieszczenia plików w katalogu domowym.

Będzie to jednak działać tylko w przypadku niektórych rzeczy. Wiele pakietów jest podzielonych na części (pliki wykonywalne lub skrypty /usr/bin, biblioteki /libi inne dodatki /usr/shareitp.), A te lokalizacje są zakodowane na stałe przez skrypty kompilacji. Zatem jeśli spróbujesz wciągnąć coś takiego do tego ~, to się zepsuje. Możesz spędzić godziny na rozwiązywaniu zależności, ale możesz robić coś pożytecznego ze swoim czasem, na przykład znaleźć lekarstwo na raka lub pochłonąć trochę piękna na świecie.

O wiele lepiej zrobiłbyś po prostu pobrać nieopakowaną wersję od tego, kto pisze oprogramowanie. Prawie całe darmowe oprogramowanie jest dostępne w postaci skompresowanego archiwum jako źródła, więc weź to i po prostu skompiluj. Nie robisz make installkroku. Twoja aplikacja jest zbudowana, po prostu umieść ją tam, gdzie chcesz.

Nie wiem zbyt wiele na ten temat, ale z innych odpowiedzi wydaje się, że możesz być w stanie zainstalować pakiet w innym katalogu zamiast /za dpkgpomocą --rootparametru, a następnie zrobić katalog , chrootw którym pakiet był „ zainstalowany ”w (który może oczywiście być katalogiem w katalogu domowym użytkownika).

Aby zainstalować pakiet dla użytkownika innego niż root, może być możliwe użycie powyższego procesu z fakechrootzamiast chroot.

Oświadczenie : Nie próbowałem tego i nie mam dużego doświadczenia w momencie pisania za pomocą dpkglub chroot, ale z tego, co wiem o tych narzędziach, ten proces może po prostu działać.

Linki zawierające informacje, które mogą być przydatne dla osób, które chcą osiągnąć efekt chrootbraku rootmożliwości:

• Ta strona o montażach do wiązania tylko do odczytu (wydaje się, że może to być przydatne nawet dla osób wykonujących „standardowe”chroot
• Ta strona na serverfault.com
• Te strony o kontenerach Linux
• Strona podręcznika użytkownika dlafakechroot )

Aktualizacja

Zrobiłem teraz trochę rzeczy, które dotyczą tego tematu i dowiedziałem się więcej ...

Fragmenty (bloki konstrukcyjne środowiska lokalnego):

• Fakechroot - naśladujechroot(1)
• Debootstrap - Utwórz kolejną hierarchię systemu plików Debiana w katalogu
• Fakeroot-NG / fakeroot - Może udawać, że jest rootem dla niektórych rzeczy
• EmDebian - wariant debiana, który zajmuje mniej miejsca i jest często używany w środowiskach chroot
• binfmt_misc - Może uruchamiać pliki, używając ich interpreterów, tak jakby były rodzimymi plikami binarnymi; przydatne razem z qemu-user do pracy z plikami binarnymi (lub w (fałszywym) chroot) obcych architektur ( skrypty / qemu-binfmt-conf.sh, które są dostarczane z kodem źródłowym QEMU automatyzują to)
• Przestrzeń użytkownika Qemu - Może uruchamiać pliki binarne innych architektur; mogą być używane z niektórymi z tych narzędzi, jeśli nie obsługują niektórych architektur procesorów
• LwIP - stos sieciowy TCP / IP, który można uruchomić z przestrzeni użytkownika

Pełny (kompletni lokalni dostawcy środowiska):

• Tryb użytkownika linux - uruchamia inny system Linux jako zwykły proces / program
• Qemu - Uruchom kompletny komputer wirtualny
• PRoot - Zapewnia funkcjonalność chroot(1), mount --bind, binfmt_misci uruchamianiu programów z innych architektur używając qemu-przestrzeni użytkownika
• Przestrzenie nazw systemu Linux - umożliwia pełne rootowanie w środowisku lokalnym, gdy używane są przestrzenie nazw użytkownika , funkcja dostępna w jądrze systemu Linux w wersji 3.8 i nowszych.

Podsumowanie : Poprzez lokalną emulację lub posiadanie uprawnień roota, pakiety DEB można zainstalować dla lokalnego środowiska.

Prawdopodobnie możesz skorzystać z --rootopcji dpkginstalacji w innym katalogu. Ale prawdopodobnie wystąpią problemy, jeśli aplikacja będzie szukać rzeczy w ustalonych miejscach, takich jak /etc.

Krótko mówiąc, nie sądzę, że istnieje prosty sposób.

Możesz zmienić własność pliku wykonywalnego, aby tylko jeden użytkownik mógł go uruchomić. Następnie w razie potrzeby możesz usunąć aplikację z menu innych użytkowników.

Wątpliwy.

Deb to głównie archiwa, które po zainstalowaniu są rozpakowywane do katalogu głównego systemu plików (plus niektóre konfiguracje). Jeśli chcesz zainstalować je tylko dla jednego użytkownika, musisz jakoś zainstalować je w folderze / home / user. Nawet jeśli to zrobiłeś, nie działałyby, ponieważ pliki binarne aplikacji nie znajdą się w katalogu / usr / bin (lub coś podobnego), a system ich nie znajdzie, jeśli spróbujesz je uruchomić. Podobnie biblioteki itp. Byłyby bezużyteczne, ponieważ system nie wiedziałby, że gdzieś w / home. Możesz wypróbować metodę brutalnej siły i dostosować zmienną PATH, aby wskazywała miejsce, w którym wyodrębniasz pliki z archiwum deb, ale byłoby to nie tylko BARDZO niepewny, ale może powodować problemy ze zgodnością (np. pozycje menu nie działałyby, ponieważ GNOME rozszerza pliki .desktop do katalogu / usr / share / applications).

Ponadto, jeśli zainstalowałeś pakiet tylko dla niektórych użytkowników, może to powodować szalone problemy z zależnością, jeśli jakikolwiek inny zainstalowany przez użytkownika pakiet, który jest w konflikcie z innym pakietem, który zainstalowałeś tylko dla siebie - i prawdopodobnie pojawią się tony innych problemów związanych z zarządzaniem pakietami.

Wszystkie te problemy sprawiają, że niezwykle trudno jest zarządzać pakietami osobno dla użytkowników, więc wydaje się, że nie jest możliwe zainstalowanie ich tylko dla jednego użytkownika, ponieważ idea .debs tego nie pozwala.