Respostas:
Dependendo do que você deseja realizar, pode haver diferentes maneiras de fazer isso funcionar (ou pelo menos fornecer uma aparência hacky da funcionalidade desejada).
A instalação de software de várias maneiras se resume a disponibilizar recursos ou permitir o acesso a itens que já estão presentes no sistema.
Esteja você falando sobre conceder acesso a impressoras ou permitir que um usuário execute programas em um determinado diretório, existem maneiras de fazer isso. Embora possam ser nativas do Ubuntu, esses tipos de soluções geralmente (é claro) vão para ser adicionado após o fato de uma instalação .deb.
Aqui estão duas classes gerais de controle pós-instalação que podem ser adicionadas. Observe que, dado o ambiente certo, por exemplo, quando uma política de grupo rigidamente controlada está em vigor, isso pode ser mais fácil depois que você tiver o sistema básico em prática. Esse tipo de permissão pode até estar vinculado ao LDAP ou a um sistema semelhante que pode fornecer autenticação e autorização por usuário ou grupo.
Controle de visibilidade
Eu mesmo tive uma situação semelhante, mas no meu caso, os usuários não eram (ainda) muito sofisticados (todos com menos de 7 anos). Para mim, apenas ocultar os menus do Gnome e / ou remover os lançadores da área de trabalho funcionou.
A remoção do bit executável dos diretórios elimina a capacidade dos processos de pesquisar ou percorrê-los. Ele pode efetivamente torná-los invisíveis e, em termos de usuário, torná-los indisponíveis. Se você possui uma política de sistema padrão que cria menus com base no acesso a arquivos, por exemplo, é possível instalar esse tipo de solução cosmética e, em seguida, trabalhar para instalações subseqüentes com pouco esforço adicional.
Controle de execução O controle do recurso pode ser feito por meio de permissões Unix, perfis apparmor, permissões SELinux e assim por diante. Pode haver outros níveis de filtragem de controle que podem entrar em jogo, dependendo do aplicativo. Na ausência de soluções mais direcionadas, talvez seja necessário escrever wrappers em torno de determinados programas para controlar o acesso do usuário ou do processo.
Bem dpkg, não irá ajudá-lo, pois este não é o seu objetivo de design. Ele deseja ser um único censo de pacotes raiz de propriedade instalado em um sistema.
A única coisa que vem à mente é apenas extrair o pacote e tentar colocar os arquivos manualmente no diretório home.
No entanto, isso só funcionará para algumas coisas. Muitos pacotes são divididos em partes (executáveis ou scripts /usr/bin, bibliotecas /libe outras informações /usr/share, etc.) e esses locais são codificados pelos scripts de construção. Portanto, se você tentar puxar algo assim ~, ele quebrará. Você pode passar horas relaxando as dependências, mas pode estar fazendo algo útil com o seu tempo, como encontrar a cura para o câncer ou absorver parte da beleza do mundo.
Você faria muito melhor apenas pegar uma versão não empacotada de quem escreve o software. Quase todo software livre está disponível em algum tipo de arquivo compactado como fonte, então pegue isso e apenas construa-o. Você não faz o make installpasso. Seu aplicativo foi criado, basta colocá-lo onde quiser.
/etc/init, procura arquivos de configuração /etcou possui outros caminhos codificados.
./configure --prefix=$HOME/local.
Eu não sei muito sobre este assunto, mas parece das outras respostas que você pode ser capaz de instalar um pacote para outro diretório em vez de /com dpkg, usando o --rootparâmetro, e depois fazer um chrootà dir qual o pacote foi " instalado "em (é claro que pode ser um diretório no diretório inicial do usuário).
Para instalar um pacote para um usuário que rootnão seja, pode ser possível usar o processo acima com em fakechrootvez de chroot.
Disclaimer : Eu não tentar isso, e não têm muita experiência no momento de escrever com dpkgou chroot, mas do que eu não sei sobre essas ferramentas, este processo apenas pode trabalhar.
Links que contêm informações que podem ser úteis para pessoas que desejam obter o efeito chrootsem rootrecursos:
chrootfakechroot )Agora fiz um pouco de coisas que tocam nesse assunto e descobri um pouco mais ...
Fragmentos (blocos de construção do ambiente local):
chroot(1)Completo (fornecedores locais completos de ambiente):
chroot(1), mount --bind, binfmt_misc, e correndo binários de outras arquiteturas usando qemu-user-spaceResumo : Ao emular ou ter privilégios de root localmente, os pacotes DEB podem ser instalados em um ambiente local.
Você provavelmente pode usar a --rootopção de dpkginstalar em outro diretório. Mas provavelmente terá problemas se o aplicativo procurar coisas em locais fixos como /etc.
Em suma, não acho que exista uma maneira fácil.
Você pode alterar a propriedade do arquivo executável para que apenas um usuário possa executá-lo. Em seguida, se necessário, você pode remover o aplicativo dos menus de outros usuários.
~/bin. Há uma ambiguidade nesta pergunta sobre se Takkat deseja restringir o acesso / visibilidade de um aplicativo multiusuário ou se deseja instalar um aplicativo para usuário único. As perguntas de você e de arranjo usam a interpretação anterior, e o restante assume a segunda.
Duvidoso.
Os deb's são principalmente arquivos que são extraídos para a raiz do seu sistema de arquivos quando instalados (mais algumas configurações). Se você quiser instalá-los apenas para um usuário, precisará instalá-los de alguma forma na pasta / home / user. Mesmo se você o fizesse, eles não funcionariam, pois os binários de aplicativos não pousariam em / usr / bin (ou sth similar) e o sistema não os encontrará se você tentar iniciá-los. Da mesma forma, as bibliotecas etc. seriam inúteis, pois o sistema não saberia que há algum lugar na / home. Você pode tentar a abordagem de força bruta e ajustar a variável PATH para apontar para onde você extraiu os arquivos do arquivo deb, mas isso não seria apenas MUITO inseguro, mas pode causar problemas de compatibilidade (as entradas do menu fe não funcionariam, pois o GNOME estende os arquivos .desktop para / usr / share / applications).
Além disso, se você instalou um pacote apenas para alguns usuários, isso pode causar problemas de dependência, se qualquer outro usuário instalou um pacote que conflitasse com outro que você instalou apenas para você - e possivelmente surgissem vários outros problemas relacionados ao gerenciamento de pacotes.
Todos esses problemas tornam extremamente difícil gerenciar pacotes separadamente para usuários, portanto, parece que não é possível instalá-los apenas para um usuário, porque a idéia por trás dos .debs não permite isso.