Revisado, incorporando o insight de Dmytro em relação aos comandos xhost necessários, melhor uso de sudo , tornando isso muito mais simples, & amp; equipando /home/foxy/ com os arquivos necessários. Funciona para mim no dia 16.04 com o Openbox simples (como um Lubuntu mais enxuto).
Sim, você poderia fazer isso. Criar outra conta de usuário, vamos chamá-lo de "foxy", com algo como configurações do sistema, ou a partir de uma linha de comando:
sudo adduser foxy
Agora você precisa fornecer a esse usuário os arquivos de configuração necessários para usar o Firefox. Provavelmente, você pode fazer isso da maneira mais adequada, registrando como foxy e fazendo de lá, mas descobri que era suficiente copiar os "arquivos de pontos" "ocultos", como .config e .mozilla do meu diretório home em /home/foxy/ & amp; então:
chown -R foxy:foxy /home/foxy
Neste ponto, como você não precisa mais efetuar login como foxy, pode ser uma boa ideia redefinir a senha do foxy para uma string absurdamente longa e aleatória. Seriamente longo e aleatório desde que você não precisará se lembrar disto. Isso é semelhante à abordagem usada pelo Ubuntu para desativar parcialmente a conta raiz. Isso não é grande coisa, já que foxy não vai estar no arquivo sudoers de qualquer maneira, mas contanto que estejamos sendo seriamente durões noid, vamos até o fim. Como você precisará inseri-lo duas vezes, você o desejará na área de transferência ou em um terminal ou editor aberto para copiá-lo. Mas tenha cuidado para não escrevê-lo em uma unidade. Você pode até criar e montar um sistema de arquivos ramfs e escrever um arquivo de texto, abrir o arquivo de texto e criar sua longa cadeia aleatória e copiar a partir daí. Para propósitos especiais de alta segurança, o ramfs é superior ao tmpfs porque ele nunca é gravado em swap. (Mas tenha cuidado ao usá-lo de maneira mais geral, pois ele utilizará alegremente TODA a sua memória RAM, se você continuar colocando as coisas nela.) De qualquer forma, para alterar a senha do foxy, use:
sudo passwd foxy
Agora fazemos dois pequenos scripts. Vamos chamar o primeiro ffx e colocá-lo em algum diretório no caminho. Assim:
#!/bin/bash
# This file, ffx, needs to go in a directory on the path
sudo /path/to/a_password_exempted_directory/ffx_2.sh
(Você provavelmente poderia fazer isso como uma função ou um alias e carregá-lo com seu perfil bash ou um dos arquivos similares, em vez de torná-lo um script em seu caminho, se preferir, mas eu não testei isso. )
O outro chamaremos ffx_2.sh e colocaremos um diretório que tenha sido isentado do requisito de digitar uma senha com sudo com as linhas apropriadas em /etc/sudoers . Assim:
#!/bin/bash
# This needs to go in a directory that is exempted from password requirement in /etc/sudoers
# Allows foxy to access the logged in user's xserver
xhost nis:foxy@
# starts firefox as foxy with home set to /home/foxy
sudo -u foxy --set-home firefox
# Removes foxy's privilege to use the xserver
xhost -nis:foxy@
Estou seguindo a abordagem de Dmytro e ativando o acesso do Fox ao servidor x somente quando estiver usando o Firefox e desligando-o depois. Eu não acho que isso seja realmente necessário. Talvez seja mais seguro, mas isso não é óbvio para mim. Eu acho que você pode realmente apenas executar o primeiro comando xhost:
xhost nis:foxy@
ONCE & amp; então o acesso do foxy persistirá durante as reinicializações. Se eu estiver certo e você fizer dessa maneira, você pode tirar os dois comandos xhost do script, depois de executar o primeiro comando uma vez.
De qualquer forma, você pode invocar isso com ffx de um terminal, caixa de execução ou menu editado manualmente, como o menu Openbox ou 9menu. Você pode criar um arquivo da área de trabalho para ele e colocá-lo em /usr/share/applications e menus adaptáveis, como o menu debian do pacote menu ou, segundo me disseram, Launcher no Unity, deve pegá-lo.
Para antecipar uma objeção, este NÃO é um risco de segurança como seria o sudo firefox ou gksudo firefox . Sudo e comandos semelhantes são fundamentalmente sobre como fazer algo como outro usuário. Mas eles estão acostumados a fazer algo como ROOT com tanta frequência, eles usam como padrão -u root (o que você também pode fazer explicitamente) para salvar os pressionamentos de tecla. Não está usando o sudo com o Firefox que é perigoso, ele está usando o sudo para rodar o Firefox AS ROOT que é perigoso. Quando você usa a opção -u e especifica outro usuário comum, não está executando o Firefox como root.
Comparação com a abordagem de bloqueio de script:
contras:
-
mais trabalho para implementar do que noscript ou librescript
-
menos de uma abordagem "padrão"
-
bloqueadores de script PODEM reduzir o uso de recursos, isso não acontece
pros:
-
O Firefox pode acessar todas as funções de sites dependentes de scripts.
-
Não requer ajustes após a implementação inicial.
-
Mais fácil de usar.
-
Você ainda pode usar as extensões do Firefox para reduzir o uso de recursos. Noscript não é a única opção para isso. Flashblock, FlashStopper, Gifblock, Bloco de Imagem, etc.