Risposte:
A seconda di ciò che vuoi realizzare, potrebbero esserci diversi modi per farlo funzionare (o almeno dare una parvenza assurda alla funzionalità che desideri).
L'installazione del software dipende in molti modi dalla disponibilità di risorse o dall'accesso a cose già presenti sul sistema.
Sia che tu stia parlando di concedere l'accesso alle stampanti o di consentire a un utente di eseguire programmi in una determinata directory, ci sono modi per farlo, e sebbene possano essere nativi di Ubuntu, questi tipi di soluzioni generalmente (ovviamente) essere aggiunto dopo il fatto di un'installazione .deb.
Ecco due classi generali di controllo post-installazione che possono essere aggiunte. Si noti che, dato il giusto ambiente, ad esempio quando è in atto una politica di gruppo strettamente controllata, questo potrebbe essere più facile una volta che è stato installato il sistema di base. Questo tipo di autorizzazione può anche essere legata a LDAP o un sistema simile che può fornire autenticazione e autorizzazione per utente o gruppo.
Controllo della visibilità
Ho avuto una situazione forse in qualche modo simile, ma nel mio caso gli utenti non erano (ancora) molto sofisticati (tutti avevano meno di 7 anni). Per me, basta nascondere i menu di Gnome e / o rimuovere i desktop launcher ha funzionato.
La rimozione del bit eseguibile dalle directory elimina la capacità dei processi di cercarli o attraversarli. Può renderli effettivamente invisibili e, per quanto riguarda l'utente, renderli non disponibili. Se si dispone di un criterio di sistema predefinito che crea menu basati sull'accesso ai file, ad esempio, è possibile ottenere questo tipo di soluzione cosmetica e quindi farlo funzionare per le installazioni successive con un piccolo sforzo aggiuntivo.
Controllo dell'esecuzione Il controllo
della risorsa può essere effettuato tramite autorizzazioni Unix, profili apparmor, autorizzazioni SELinux e così via. Potrebbero esserci altri livelli di filtro di controllo che potrebbero entrare in gioco a seconda dell'applicazione. In assenza di soluzioni più mirate, potrebbe essere necessario scrivere wrapper attorno a determinati programmi per controllare l'accesso dell'utente o del processo.
Beh dpkg, non ti aiuterà in quanto questo non è il suo obiettivo progettuale. Vuole essere un unico censimento di proprietà di root dei pacchetti installati su un sistema.
L'unica cosa che viene in mente è solo estrarre il pacchetto e provare a posizionare i file manualmente nella directory home.
Tuttavia, questo funzionerà solo per alcune cose. Molti pacchetti sono suddivisi in blocchi (eseguibili o script in /usr/bin, librerie in /libe altri abiti in /usr/share, ecc.) E queste posizioni sono codificate dagli script di build. Quindi, se provi a inserire qualcosa del genere ~, si romperà. Potresti passare ore a rilassare le dipendenze, ma potresti fare qualcosa di utile con il tuo tempo come trovare la cura per il cancro o assorbire parte della bellezza del mondo.
Faresti molto meglio solo per prendere una versione non impacchettata da chiunque scriva il software. Quasi tutto il software gratuito è disponibile in qualche forma di archivio compresso come sorgente, quindi prendilo e costruiscilo. Non fai il make installpasso. La tua app è costruita, basta metterla dove vuoi.
/etc/init, cerca i file di configurazione /etco ha alcuni altri percorsi codificati.
./configure --prefix=$HOME/local.
Non ne so molto di questo argomento, ma dalle altre risposte sembra che potresti essere in grado di installare un pacchetto in un'altra directory invece che /con dpkg, usando il --rootparametro, e quindi fare un chrootdir alla directory che il pacchetto era " installato "in (che ovviamente può essere una directory nella home directory dell'utente).
Per installare un pacchetto per un utente diverso da root, potrebbe essere possibile utilizzare il processo precedente con fakechrootanziché chroot.
Diniego : Non ho provato questo, e non ho molta esperienza al momento della scrittura con dpkgo chroot, ma da quello che ne so di questi strumenti, questo processo solo potrebbe funzionare.
Collegamenti che contengono informazioni che possono essere utili per le persone che vogliono ottenere l'effetto chrootsenza rootcapacità:
chrootfakechroot )Ora ho fatto un po 'di cose che toccano questo argomento e ne ho scoperto un po' di più ...
Frammenti (elementi costitutivi dell'ambiente locale):
chroot(1)Completo (provider di ambiente locale completo):
chroot(1), mount --bind, binfmt_misc, e l'esecuzione di file binari da altre architetture utilizzando qemu-user-spaceRiepilogo : emulando o effettivamente disponendo dei privilegi di root localmente, i pacchetti DEB possono essere installati per un ambiente locale.
Probabilmente puoi usare l' --rootopzione di dpkginstallare in un'altra directory. Ma probabilmente si verificheranno problemi se l'applicazione cerca elementi in luoghi fissi come /etc.
In breve, non penso che ci sia un modo semplice.
È possibile modificare la proprietà del file eseguibile in modo che solo un utente sia in grado di eseguirlo. Quindi, se necessario, è possibile rimuovere l'applicazione dai menu di altri utenti.
~/bin. C'è un'ambiguità in questa domanda sul fatto che Takkat voglia limitare l'accesso / la visibilità di un'applicazione multiutente o se desidera installare un'applicazione monoutente. Le tue domande e organizzano la prima interpretazione, mentre il resto assume la seconda.
Dubbioso.
I deb sono principalmente archivi che vengono estratti nella radice del filesystem quando vengono installati (oltre ad alcune configurazioni). Se si desidera installarli solo per un utente, è necessario installarli in qualche modo nella cartella / home / utente. Anche se lo facessi, non funzionerebbero, poiché i binari dell'applicazione non atterreranno in / usr / bin (o sth simili) e il sistema non li troverà se proverai ad avviarli. Allo stesso modo le librerie ecc. Sarebbero inutili, poiché il sistema non saprebbe che ci sono da qualche parte in / home. Potresti provare l' approccio della forza bruta e regolare la variabile PATH in modo che punti a dove hai estratto i file dall'archivio deb, ma non sarebbe MOLTO insicuro, ma potrebbe causare problemi di compatibilità (le voci di menu non funzionerebbero, poiché GNOME estende i file .desktop in / usr / share / applicazioni).
Inoltre, se hai installato un pacchetto solo per alcuni utenti, ciò potrebbe causare pazzi problemi di dipendenza, se un altro pacchetto installato da un utente che fosse in conflitto con un altro che avevi installato solo per te stesso - e probabilmente appariranno tonnellate di altri problemi relativi alla gestione dei pacchetti.
Tutti questi problemi rendono estremamente difficile la gestione dei pacchetti separatamente per gli utenti, quindi sembra che non sia possibile installarli solo per un utente, perché l'idea dietro .debs non lo consente.