Ao instalar aplicativos pelo centro de software ou por um arquivo DEB, eles geralmente serão instalados em todo o sistema para todos os usuários.

Existe uma maneira de instalar um aplicativo apenas para um único usuário?

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.

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:

• Esta página sobre montagens de ligação somente leitura (parece que isso pode ser útil mesmo para pessoas que fazem um "padrão"chroot
• Esta página em serverfault.com
• Estas páginas sobre Linux Containers
• A página de manual parafakechroot )

Atualizar

Agora fiz um pouco de coisas que tocam nesse assunto e descobri um pouco mais ...

Fragmentos (blocos de construção do ambiente local):

• Fakechroot - emulachroot(1)
• Debootstrap - Crie outra hierarquia de sistemas de arquivos Debian dentro de um diretório
• Fakeroot-NG / fakeroot - Pode fingir ser raiz de algumas coisas
• EmDebian - Uma variante debian que utiliza menos espaço e é frequentemente usada em ambientes chroot
• binfmt_misc - pode executar arquivos usando seus intérpretes, como se fossem binários nativos; útil em conjunto com o qemu-user para trabalhar com binários (ou em um chroot (falso)) de arquiteturas estrangeiras ( scripts / qemu-binfmt-conf.sh que vem com o código-fonte do QEMU automatiza isso)
• Espaço do usuário Qemu - Pode executar binários de outras arquiteturas; pode ser usado com algumas dessas ferramentas quando elas não suportam algumas arquiteturas de processador
• LwIP - Uma pilha de rede TCP / IP que pode ser executada no espaço do usuário

Completo (fornecedores locais completos de ambiente):

• User mode linux - executa outro sistema linux como um processo / programa regular
• Qemu - Execute um computador virtual completo
• PROOT - fornece funcionalidades de chroot(1), mount --bind, binfmt_misc, e correndo binários de outras arquiteturas usando qemu-user-space
• Namespaces do Linux - Permite ter raiz completa dentro de um ambiente local, ao usar os namespaces de usuário , um recurso disponível nas versões 3.8 e posteriores do kernel Linux 3.8.

Resumo : 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.

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.