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 sûr) ê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, lorsqu'une stratégie de groupe étroitement contrôlée est en place, cela pourrait être plus facile une fois 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 eu 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 de Gnome et supprimer les lanceurs de postes de travail fonctionnaient.

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 la faire fonctionner pour des installations ultérieures avec peu d'effort supplémentaire.

Contrôle de l' exécution Le contrôle de la ressource peut être effectué via des autorisations Unix, des profils apparmor, des 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.

Eh bien dpkgne vous aidera pas car ce n'est pas son objectif de conception. 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. De nombreux packages sont scindés en morceaux (fichiers exécutables ou scripts /usr/bin, bibliothèques /libet autres éléments /usr/share, etc.) et ces emplacements sont codés en dur par les scripts de construction. Ainsi, si vous essayez d’ ~intégrer quelque chose comme cela , cela casserait. 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. Tu ne fais pas le make installpas. Votre application est construite, placez-la où vous le souhaitez.

Je ne sais pas trop à ce sujet, mais il semble, d’autres réponses, que vous pourrez peut-être installer un paquet dans un autre répertoire au lieu de /avec dpkg, en utilisant le --rootparamètre, puis faire un chrootdans le répertoire dans lequel se trouvait le paquet " installed "in (qui peut bien sûr être un répertoire dans le répertoire personnel de l'utilisateur).

Pour installer un package pour un utilisateur autre que root, vous pouvez éventuellement utiliser le processus ci-dessus à la fakechrootplace de chroot.

Avertissement : Je n'ai pas essayé cela, et ne pas avoir beaucoup d' expérience au moment de l' écriture avec dpkgou chroot, mais de ce que je ne sais sur ces outils, ce processus juste pourrait fonctionner.

Liens contenant des informations pouvant être utiles aux personnes souhaitant obtenir des résultats chrootsans rootcapacités:

• Cette page sur les montages de liens en lecture seule (il semble que cela puisse être utile même aux personnes effectuant un "standard"chroot
• Cette page sur serverfault.com
• Ces pages sur les conteneurs Linux
• La page de manuel pourfakechroot )

Mise à 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 - émulechroot(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 la racine de certaines choses
• EmDebian - Une variante de Debian qui utilise moins d’espace et qui 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 Qemu - 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
• Qemu - Exécuter un ordinateur virtuel complet
• Proot - Fournit des fonctionnalités de chroot(1), mount --bind, binfmt_miscet binaires en cours d' exécution d'autres architectures utilisant qemu-espace utilisateur
• Espaces de noms Linux - Permet d'avoir une racine complète dans un environnement local, lors de l'utilisation d'espaces de noms d'utilisateurs , une 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' --rootoption de dpkgpour installer dans un autre répertoire. Mais vous rencontrerez probablement des problèmes si l’application recherche des éléments à des endroits 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 des archives qui sont extraites à la racine de votre système de fichiers lors de l'installation (plus de la configuration). Si vous voulez les installer uniquement pour un utilisateur, vous devez les installer dans le dossier / home / user. Même si vous le faisiez, cela ne fonctionnerait pas, par exemple, les applications binaires n'atterriront pas dans / usr / bin (ou 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 par force brute et ajuster la variable PATH pour pointer là où vous avez extrait les fichiers de l’archive deb, mais ce ne serait pas seulement VERY problèmes de compatibilité (par exemple, les entrées de menu ne fonctionneraient pas, car GNOME examinait les fichiers .desktop 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 installé par 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.