Comment installer une application par fichier DEB pour un seul utilisateur?
Lors de l'installation d'applications via le centre logiciel ou via un fichier DEB, celles-ci sont généralement installées sur l'ensemble du système, pour tous les utilisateurs.
Est-il possible d'installer une application pour un seul utilisateur?
Selon ce que vous voulez accomplir, il peut y avoir différentes façons de faire fonctionner le logiciel (ou du moins de lui donner un semblant de fonctionnalité).
L'installation d'un logiciel se résume à plusieurs égards à la mise à disposition de ressources ou à l'accès à des éléments déjà présents sur le système.
Que vous parliez d’accorder l’accès aux imprimantes ou de permettre à un utilisateur d’exécuter des programmes dans un répertoire donné, il existe des moyens de le faire. Bien qu’ils soient natifs d’Ubuntu, ces types de solutions vont généralement (bien entendu) être ajouté après le fait d'une installation .deb.
Voici deux classes générales de contrôle post-installation pouvant être ajoutées. Notez que, dans le bon environnement, par exemple quand une stratégie de groupe étroitement contrôlée est en place, cela peut être plus facile une fois que vous avez le système de base en place. Ce type d'autorisation peut même être lié à LDAP ou à un système similaire pouvant donner une authentification et une autorisation par groupe ou utilisateur.
Contrôle de la visibilité
J'ai moi-même vécu une situation quelque peu similaire, mais dans mon cas, les utilisateurs n'étaient pas (encore) très sophistiqués (tous âgés de moins de 7 ans). Pour moi, masquer les menus Gnome et/ou supprimer les lanceurs de bureau fonctionnait.
Supprimer le bit exécutable des répertoires élimine la possibilité pour les processus de les rechercher ou de les parcourir. Cela peut effectivement les rendre invisibles et, du point de vue de l'utilisateur, les rendre indisponibles. Si vous avez une stratégie système par défaut qui crée des menus basés sur l'accès aux fichiers, par exemple, vous pouvez mettre en place ce type de solution esthétique, puis l'utiliser pour les installations ultérieures avec peu d'effort supplémentaire.
Contrôle d'exécution
Le contrôle de la ressource peut être effectué via les autorisations Unix, les profils apparmor, les autorisations SELinux, etc. Il peut y avoir d'autres niveaux de filtrage de contrôle qui peuvent entrer en jeu en fonction de l'application. En l'absence de solutions plus ciblées, vous devrez peut-être écrire des wrappers autour de certains programmes pour contrôler l'accès des utilisateurs ou des processus.
dpkg ne vous aidera pas car ce n’est pas son objectif. Il veut être un recensement unique, appartenant à la racine, des paquets installés sur un système.
La seule chose qui me vient à l’esprit est simplement d’extraire le paquet et d’essayer de placer les fichiers manuellement dans le répertoire personnel.
Cependant, cela ne fonctionnera que pour certaines choses. Beaucoup de paquets sont divisés en morceaux (les exécutables ou les scripts dans /usr/bin, les bibliothèques dans /lib et les autres éléments dans /usr/share, etc.) et ces emplacements sont codés en dur par les scripts de construction. Ainsi, si vous essayez de saisir quelque chose comme ceci dans ~, cela se brisera. Vous pourriez passer des heures à décompresser les dépendances, mais vous pourriez aussi faire quelque chose de utile, comme trouver un remède contre le cancer ou absorber une partie de la beauté du monde.
Vous feriez beaucoup mieux de simplement récupérer une version non empaquetée de quiconque écrit le logiciel. Presque tous les logiciels libres sont disponibles sous forme d'archive compressée en tant que source, saisissez-le et construisez-le. Vous ne faites pas l'étape make install. Votre application est construite, placez-la où vous le souhaitez.
Je ne connais pas grand-chose à ce sujet, mais d'après les autres réponses, vous pourrez peut-être installer un paquet dans un autre répertoire au lieu de / avec dpkg, en utilisant le paramètre --root, puis faites un chroot au répertoire dans lequel le paquet a été "installé" (ce qui peut bien sûr être un répertoire dans le répertoire de base de l'utilisateur).
Pour installer un package pour un utilisateur autre que root, vous pouvez éventuellement utiliser le processus ci-dessus avec fakechroot au lieu de chroot.
Disclaimer : Je n’ai pas essayé cela, et n’ai pas beaucoup d’expérience au moment de la rédaction de dpkg ou chroot, mais à partir de quoi je do connaître ces outils, ce processus vient pourrait fonctionner.
Liens qui contiennent des informations pouvant être utiles aux personnes désirant obtenir l'effet de chroot sans les capacités de root:
- This page sur les montages de liaisons en lecture seule (il semble que cela puisse être utile même aux personnes effectuant un "standard"
chroot - Cette page sur serverfault.com
- Thispages à propos des conteneurs Linux
- La page de manuel de
fakechroot)
Mettre à jour
J'ai maintenant fait un peu avec des choses qui touchent à ce sujet et en ai découvert plus ...
Fragments (blocs de construction de l'environnement local):
- Fakechroot - émule
chroot(1) - Debootstrap - Crée une autre hiérarchie de système de fichiers Debian dans un répertoire
- Fakeroot-NG / fakeroot - Peut prétendre être root pour certaines choses
- EmDebian - Une variante debian qui utilise moins d'espace et est souvent utilisée dans des environnements chroot
- binfmt_misc - Peut exécuter des fichiers, à l'aide de leurs interpréteurs, comme s'il s'agissait de fichiers binaires natifs. utile avec qemu-user pour travailler avec des binaires (ou dans un (faux) chroot) d'architectures étrangères ( scripts/qemu-binfmt-conf.sh fourni avec le code source QEMU automatise ce processus)
- espace utilisateur Qem - Peut exécuter des fichiers binaires d'autres architectures; peut être utilisé avec certains de ces outils quand ils ne supportent pas certaines architectures de processeur
- LwIP - Une pile réseau TCP/IP pouvant être exécutée à partir de l'espace utilisateur
Complet (fournisseurs d’environnement local complets):
- Mode utilisateur linux - exécute un autre système linux en tant que processus/programme régulier
- Qem - Exécuter un ordinateur virtuel complet
- PRoot - Fournit les fonctionnalités de
chroot(1),mount --bind,binfmt_miscet l'exécution de binaires à partir d'autres architectures à l'aide de qemu-user-space - espaces de noms Linux - Permet d'avoir une racine complète dans un environnement local, lorsque espaces de noms d'utilisateurs , fonctionnalité disponible dans les versions 3.8 et ultérieures du noyau Linux.
Résumé : en émulant ou en disposant réellement les privilèges root localement, les packages DEB peuvent être installés pour un environnement local.
Vous pouvez probablement utiliser l'option --root de dpkg pour l'installer dans un autre répertoire. Mais des problèmes se poseront probablement si l’application recherche des éléments à des emplacements fixes tels que /etc.
En bref, je ne pense pas qu'il existe un moyen simple.
Vous pouvez modifier la propriété du fichier exécutable afin qu'un seul utilisateur puisse l'exécuter. Ensuite, si nécessaire, vous pouvez supprimer l'application des menus d'autres utilisateurs.
Douteux.
Les deb sont principalement archives qui sont extraits vers la racine de votre système de fichiers une fois installés (plus de la configuration). Si vous souhaitez les installer uniquement pour un utilisateur, vous devez les installer dans le dossier/home/user. Même si vous le faisiez, ils ne fonctionneraient pas, comme f.e. les binaires d'application n'atterriront pas dans/usr/bin (ou sth similaire), et le système ne les trouvera pas si vous essayez de les lancer. De même, les bibliothèques, etc. seraient inutiles, car le système ne saurait pas qu'il y en ait quelque part dans/home. Vous pouvez essayer l’approche brute-force et ajuster la variable PATH pour pointer là où vous avez extrait les fichiers de l’archive deb, mais ce ne serait pas le cas. only VERY non sécurisé, mais peut entraîner des problèmes de compatibilité (par exemple, les entrées de menu ne fonctionneraient pas car GNOME détecte que les fichiers .desktop se trouvent dans/usr/share/applications).
En outre, si vous installez un package uniquement pour certains utilisateurs, des problèmes de dépendance insolites risquent de se produire. Si un autre package installé par un utilisateur était en conflit avec un autre que vous aviez installé pour vous-même, des problèmes liés à la gestion des packages pourraient apparaître.
Tous ces problèmes rendent extrêmement difficile la gestion des packages séparément pour les utilisateurs. Il semble donc impossible de les installer pour un seul utilisateur, car l'idée derrière le .debs ne le permet pas.