Will Wayland já suportou sudo gráfico?

Question

Na área de trabalho X, usei ocasionalmente gksudo ou apenas sudo somegui para iniciar aplicativos GUI como outro usuário, incluindo root. Eu descobri recentemente que isso não é possível em desktops contemporâneos (início de 2018) Wayland. Todos os aplicativos devem ser lançados como o usuário atual da área de trabalho e estão limitados aos privilégios desse usuário.

Este é um recurso permanente do Wayland (lá por design), ou o uso do mesmo tipo é um aprimoramento que ainda não foi implementado?

Estou procurando uma declaração documentada (roteiro, página de design ...), sem preferência ou opinião.

    

Answer 1

Is this a permanent feature of Wayland (there by design)

Não. Isso não tem nada a ver com o protocolo do wayland. É mais uma questão de configuração do ambiente.

Wayland usa um soquete, seu nome é armazenado em WAYLAND_DISPLAY . Ele está localizado em XDG_RUNTIME_DIR , que normalmente é configurado apenas para acesso do usuário. Mas o root também pode acessá-lo. (Alguns aplicativos também consideram XDG_SESSION_TYPE , que pode ter valores wayland ou x11 para decidir se deve usar X ou Wayland.)

sudo exclui a maioria das variáveis de ambiente, incluindo XDG_RUNTIME_DIR e WAYLAND_DISPLAY .

Você pode executar aplicativos de caminhos da cidade como root com:

sudo env XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR WAYLAND_SOCKET=$WAYLAND_SOCKET waylandapplication

ou menor com -EH para preservar quase todas as variáveis de ambiente (mas configurando HOME para /root ). Isso incluirá DISPLAY e XAUTHORITY para o acesso a Xwayland também:

sudo -EH application

No entanto, se o aplicativo em execução como root gravar alguma coisa em XDG_RUNTIME_DIR , isso poderá causar problemas de permissão de arquivo para aplicativos do usuário.

No entanto, a execução de aplicativos gráficos como root no wayland é muito menos um problema de segurança do que no X11.

Para evitar o uso acidental do X11, você pode executar sem DISPLAY :

sudo -EH env DISPLAY=  waylandapplication

I'm looking for a documented statement (roadmap, design page...), not preference or opinion.

A documentação do Wayland menciona WAYLAND_DISPLAY , mas não encontro nada sobre XDG_RUNTIME_DIR . No entanto, todos os compositores de rotas incluindo a implementação de referência weston dependem de XDG_RUNTIME_DIR .

Se WAYLAND_DISPLAY estivesse em outro local, não seria um problema executar aplicativos de usuários arbitrários na mesma exibição de rota. Mas XDG_RUNTIME_DIR está especificado para ser restrito ao usuário que efetuou login e deve conter soquetes relacionados ao usuário:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

Os problemas com a execução de outro usuário ou root no wayland estão relacionados à especificação XDG_RUNTIME_DIR do que ao próprio caminho. Se você especificar um XDG_RUNTIME_DIR em /tmp personalizado com acesso arbitrário (assim quebrando sua especificação), todos os usuários poderão usar a exibição da rota.

Há alguma esperança de que o futuro não precise de XDG_RUNTIME_DIR , mas isso depende da implementação: Wayland docu cap.4 :

Beginning in Wayland 1.15, implementations can optionally support server socket endpoints located at arbitrary locations in the filesystem by setting WAYLAND_DISPLAY to the absolute path at which the server endpoint listens.

    

Answer 2

Embora eu não esteja respondendo sua pergunta diretamente, acho que há pessoas que podem ter acabado aqui por causa do mesmo problema.

Este é um script que eu fiz é uma solução para pessoas que precisam executar aplicativos gráficos (como Gedit , Synaptic ou GParted ) como root via sudo em uma sessão Wayland :

link

Importado aqui:

#!/usr/bin/env bash

#
# Enable root access to x-windows system.
#
# Motivation: Trying to run a graphical application as root via su, sudo in a 
# Wayland session (e.g. GParted or Gedit), will fail. Apps which use polkit to
# request administrator permissions for just certain operations and only when 
# needed are not affected (they are not started as root right away). 
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1274451
#
# Based on a Reddit comment.
# [2] https://www.reddit.com/r/Fedora/comments/5eb633/solution_running_graphical_app_with_sudo_in/

if (( $# != 1 )); then
    echo "Illegal number of parameters."
    echo
    echo "Usage: wsudo [command]"
    exit 1
fi

for cmd in sudo xhost; do
    if ! type -P $cmd &>/dev/null; then
        echo "$cmd it's not installed. Aborting." >&2
        exit 1
    fi
done

xhost +SI:localuser:root
sudo $1
#disable root access after application terminates
xhost -SI:localuser:root
#print access status to allow verification that root access was removed
xhost