Running GUI applications as root (Português)

From ArchWiki
Status de tradução: Esse artigo é uma tradução de Running GUI applications as root. Data da última tradução: 2020-06-21. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.
Atenção: Todos os métodos a seguir têm implicações de segurança que os usuários devem estar cientes. Como colocado por Emmanuele Bassi, um desenvolvedor do GNOME: "não existem razões *reais* tecnológicas e comprovadas por que alguém deveria executar um aplicativo GUI como root. Ao executar aplicativos GUI como um usuário administrador, você está literalmente executando milhões de linhas de código que não foram auditados corretamente para executar sob privilégios elevados, você também está executando código que tocará em arquivos dentro de seu $HOME e poderá alterar sua propriedade no sistema de arquivos; conectar-se via IPC a ainda mais códigos em execução, etc. Você está abrindo uma enorme falha de segurança [...]."[1]

Evita executar aplicativos gráficos como root se possível, veja #Contornar aplicativos gráficos como root.

Contornar aplicativos gráficos como root

sudoedit

Para editar arquivos como root, use sudoedit.

GVFS

O acesso aos arquivos e diretórios privilegiados é possível através do GVFS especificando o backend admin no esquema de URI[2][3], por exemplo: 

$ nautilus admin:///root/

ou 

$ gedit admin:///etc/fstab
Dica: Isso também pode ser feito na barra de local/seletor de arquivo do aplicativo: por exemplo, no nautilus ou no gedit, digite Ctrl+L e preencha o esquema admin:// no caminho do recurso. O mesmo efeito pode ser obtido pela barra de endereços de servidor Outros locais.

Xorg

Por padrão, e por motivos de segurança, o root não poderá se conectar a um servidor X de usuário não-root. Existem várias maneiras de permitir que o root faça isso, no entanto, se necessário.

A maneira correta e recomendada de executar aplicativos GUI no X com privilégios elevados é criar uma política Polkit, conforme mostrado em neste tópico de fórum. Isto deve, no entanto, "ser usado somente para programas legados", como pkexec(1) lembra. Os aplicativos devem "adiar as operações privilegiadas para um pedaço de código auditável, autocontido, mínimo, que é executado após executar um escalonamento de privilégios e ser descartado quando não for necessário"[4]. Isso pode ser o objeto de um relatório de bug para o projeto upstream.

Métodos pontuais

Esses métodos envolvem o aplicativo em uma estrutura de elevação e descartam os privilégios adquiridos depois que ele sai: 

$ kdesu aplicativo

$ sudo aplicativo
  • suxAUR (wrapper do su que transferirá suas credenciais X)
$ sux root aplicativo

Métodos alternativos

Esses métodos permitirão que o root se conecte a um servidor X de usuário não-root, mas apresentam níveis variados de riscos de segurança, especialmente se você executar o ssh. Se você estiver protegido por um firewall, considere-o seguro o suficiente para suas necessidades.

Xhost

Xhost pode ser usado para permitir temporariamente acesso como root.

Permitir permanentemente acesso de root

Método 1: Adicionar a linha
session         optional        pam_xauth.so

para /etc/pam.d/su e /etc/pam.d/su-l. Então, mude para seu usuário root usando su ou su -.

Método 2: Globalmente no /etc/profile

Adicione a seguinte linha ao /etc/profile: 

XAUTHORITY=/home/usuario/.Xauthority

Isso vai permitir permanentemente que o root se conecte a um servidor X de usuário não-root.

Ou meramente especifique um aplicativo em particular: 

XAUTHORITY=/home/usuario/.Xauthority nome-do-aplicativo

sendo nome-do-aplicativo o nome do aplicativo em particular (p.ex., kwrite)

Wayland

Tentar executar um aplicativo gráfico como root via su, sudo ou pkexec em uma sessão Wayland (por exemplo, GParted ou Gedit), falhará com um erro semelhante a este: 

$ sudo gedit
No protocol specified
Unable to init server: Não foi possível conectar: Conexão recusada

(gedit:2349): Gtk-WARNING **: cannot open display: :0

Antes do Wayland, a execução de aplicativos de GUI com privilégios elevados poderia ser implementada adequadamente criando uma política de Polkit ou, mais perigosamente, executando o comando em um terminal, prefixando o comando com sudo; mas sob (X)Wayland isso não funciona mais, já que o padrão foi feito para permitir que o usuário que iniciou o servidor X conectasse clientes a ele (veja o relatório de erro e os commits upstream aos quais ele se refere).

Evite executar aplicativos gráficos como root se possível, veja #Contornar aplicativos gráficos como root.

Uma solução mais versátil, embora mais insegura, permite que qualquer aplicativo gráfico seja executado como root usando o xhost.

Usar xhost

Uma solução mais versátil – embora muito menos segura – é usar xhost para permitir temporariamente que o usuário root acesse a sessão X do usuário local[5]. Para fazer isso, execute o seguinte comando como o usuário atual (não privilegiado): 

$ xhost si:localuser:root

Para remover esse acesso após o aplicativo ter sido fechado: 

$ xhost -si:localuser:root