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’access à des éléments déjà présents sur le système.

Qu’il s’agisse d’accorder l’access à des 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 être ajouté après le fait d’une installation .deb.

Voici deux classes générales de contrôle post-installation que vous pouvez append. 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 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 de 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 sharepoint 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’access 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 d’exécution
Le contrôle de la ressource peut être effectué via des permissions Unix, des profils apparmor, des permissions 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’access des utilisateurs ou des processus.

Eh bien, dpkg ne vous aidera pas car ce n’est pas son objective 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. Beaucoup de paquets sont divisés en morceaux (exécutables ou scripts dans /usr/bin , bibliothèques dans /lib et autres objects dans /usr/share , etc.) et ces emplacements sont codés en dur par les scripts de construction. Ainsi, si vous essayez d’introduire quelque chose comme ceci dans ~ , cela va casser. 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-la et construisez-la. Vous ne faites pas l’étape make install . 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 paramètre --root , puis en --root un chroot vers le répertoire dans lequel le paquet a été “installé” (qui peut bien sûr être un répertoire situé dans le répertoire de base de l’utilisateur).

Pour installer un package pour un utilisateur autre que root , il peut être possible d’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 d’écrire avec dpkg ou chroot , mais d’après ce que je sais de ces outils, ce processus pourrait bien fonctionner.

Liens contenant des informations pouvant être utiles aux personnes désirant obtenir l’effet de chroot sans capacités root :

• Cette page sur les assemblys de liens en lecture seule (il semble que cela puisse être utile même aux personnes qui font un chroot “standard”
• Cette page sur serverfault.com
• Ces pages sur les conteneurs Linux
• La page de fakechroot 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 constitutifs 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 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 binarys natifs. utile avec qemu-user pour travailler avec des binarys (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 binarys d’autres architectures; peut être utilisé avec certains de ces outils quand ils ne supportent pas certaines architectures de processeur
• LwIP – Une stack réseau TCP / IP pouvant être exécutée à partir de l’espace utilisateur

Complet (fournisseurs d’environnement locaux 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 les fonctionnalités de chroot(1) , mount --bind , binfmt_misc et l’exécution de fichiers binarys à 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, lors de l’utilisation d’espaces de noms d’utilisateurs , une fonctionnalité disponible dans les versions 3.8 et ultérieures du kernel 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 cela posera probablement des problèmes si l’application recherche des éléments à des emplacements fixes tels que /etc

En bref, je ne pense pas qu’il existe un moyen facile.

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 souhaitez 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 binarys n’atterrissent 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 TRES non sécurisé, mais pourrait aussi causer des problèmes de compatibilité (par exemple, les entrées de menu ne fonctionneraient pas.) , GNOME recherchant 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.