Pourquoi ne pas gksu / gksudo ou le lancement d'une application graphique avec sudo ne fonctionne pas avec Wayland?


44

J'ai installé Ubuntu 17.10. Maintenant, j'ai des problèmes avec gksu:

$ gksu -dg synaptic
No ask_pass set, using default!
xauth: /tmp/libgksu-HgUjgQ/.Xauthority
STARTUP_ID: gksu/synaptic/8760-0-alex-XPS-15-9530_TIME4974977
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: synaptic
buffer: -GNOME_SUDO_PASS-
brute force GNOME_SUDO_PASS ended...
Yeah, we're in...
Unable to init server: Could not connect: Connection refused
(synaptic:8767): Gtk-WARNING **: cannot open display: :1
xauth: /tmp/libgksu-HgUjgQ/.Xauthority
xauth_env: (null)
dir: /tmp/libgksu-HgUjgQ

Si je n'utilise pas -g, la boîte de dialogue de mot de passe est désactivée. Cela ressemble donc à un problème de création d’un tty pour root.

Aucun conseil?


1
gksudone fonctionnera pas dans une session Wayland , vous pouvez passer à une session Xorg et essayer.
Pomsky

2
L’erreur elle-même si une erreur X "ne peut pas ouvrir display:: 1". Wayland est conçu de cette manière et, de l'avis des développeurs, vous ne devriez pas exécuter d'applications graphiques en tant qu'utilisateur root à partir de la ligne de commande. Vous pouvez travailler avec xhost.
Panther

1
gksu -dg synaptic Vous ne devriez jamais faire ça de toute façon.
Rinzwind

3
@ N0rbert cesse d’ajouter le 17.10 aux questions qui mentionnent 17.10. Les balises de version doivent être utilisées si la question est spécifique à cette version. La plupart de ces questions sont généralement applicables partout où Wayland, GNOME Shell, etc. sont disponibles, y compris les versions passées et futures.
Muru

@maru. 16.04 LTS est en cours, 17.04 est proche de la fin de série, donc 17.10 normal signifie Wayland et GNOME Shell par défaut, ainsi la balise 17.10 est utile, je pense. Il est difficile de trouver des questions pour lesquelles les utilisateurs ont des problèmes avec 17.10, mais n’ont pas de réponses ni de commentaires ici . Ils ont besoin de réponses, mais ils ont oublié d’ajouter une balise 17.10 à la demande. Je peux arrêter d'ajouter des balises. C'était une bonne volonté.

Réponses:


55

Notez que cette réponse est spécifique aux versions d'Ubuntu utilisant Wayland, 17.10 étant la première version à utiliser Wayland par défaut.

C'est une fonctionnalité pas un bug! C'est une caractéristique de Wayland que vous ne pouvez pas démarrer d'applications graphiques en tant qu'utilisateur root à partir du terminal.

Les principales discussions portent bien entendu sur les sites Fedora. Voir le bogue Fedora n ° 1274451 et les applications graphiques ne peuvent pas être exécutées en tant que root dans Wayland (par exemple, gedit, beesu, gparted, nautilus) sur Ask Fedora . Mais il y a aussi quelques discussions sur les sites Ubuntu ( Ubuntu Devs Incertain sur l’utilisation de Wayland par défaut dans 17.10 - OMG! Ubuntu ).

Rapport de bogue Ubuntu: Impossible de lancer des applications pkexec sur la session Wayland

Solution possible - Si vous modifiez des fichiers système avec un éditeur graphique (tel que gedit), utilisez un outil de ligne de commande tel que nanoou vimou emacs. nanoest généralement plus facile pour les nouveaux utilisateurs, vimest plus puissant et a plus de fonctionnalités, voir ce tutoriel Vim ou similaire.

Quoi qu'il en soit, si vous souhaitez ou devez exécuter des applications graphiques en tant qu'utilisateur root , définissez-le en xhostpremier, ce qui oblige le repli sur Xserver.

Pour définir les autorisations, exécutez:

xhost si:localuser:root 

Lorsque vous avez terminé, pour supprimer les autorisations

xhost -si:localuser:root 

Vous pouvez ajouter une option graphique / de bureau pour le faire selon ce rapport de bogue synaptic

Les applications pkexec 'peuvent être soignées avec une xhost +si:localuser:rootmise en route automatique XDG comme suit (idée de N0rbert):

cat <<EOF | sudo tee /etc/xdg/autostart/xhost.desktop
[Desktop Entry]
Name=xhost
Comment=Fix graphical root applications
Exec="xhost +si:localuser:root"
Terminal=false
Type=Application
EOF

Vous pouvez ajouter cette commande xhost à .bashrc, mais je conseillerais une paire d'alias.

alias gsuon='xhost si:localuser:root'

alias gsuoff='xhost -si:localuser:root'

Vous pouvez nommer les alias comme vous le souhaitez.

Pour plus de détails, voir:


Revenez à Xorg

Si vous préférez Xorg pour une raison quelconque, vous pouvez choisir de s’exécuter sur Xorg lors de la connexion.

Voir Comment passez-vous de Wayland à Xorg dans Ubuntu 17.10?


Cette solution de contournement fonctionne-t-elle également avec Mir ?
Eliah Kagan

Je ne sais pas pour MIR, ça se peut.
Panther

1
Ou justexhost +local:
chaskes

18
"C'est une fonctionnalité pas un bug!" ... soupir. Ce genre de choses est exactement la raison pour laquelle je ne peux pas convaincre mes amis et collègues de passer à Linux. L'utilisation de VIM et Nano n'est pas une alternative à GEdit. Gedit fonctionne comme un bloc-notes, alors que vous devez apprendre le code CRTL pour les autres. Et prenons, par exemple, Nano en utilisant les termes tels que "Ecrire" au lieu de "Enregistrer" ... Très utilisateur peu amical.
JHBonarius

9
C’est également une chose importante à laquelle il faut avoir accès. Qu'est-il déjà arrivé à "N'essayez pas d'empêcher les personnes stupides de faire des choses stupides; vous réussirez seulement à empêcher les personnes intelligentes de faire des choses intelligentes"?
Matthew Najmon

21

entrez la description de l'image ici Solutions

À Wayland, il est souvent difficile d’exécuter des programmes d’application avec des autorisations élevées (sudo -H, gksu ...). C'est une bonne idée de faire de telles tâches avec des outils en ligne de commande.

Mais il existe des solutions de contournement, si vous avez un outil graphique, qui fonctionne bien pour vous et nécessite des autorisations élevées. (J'utilise deux de ces outils standard: le gestionnaire de paquets Synaptic synapticet l'outil de partitionnement Gparted gparted. J'utilise MakeUSB pour créer des lecteurs de démarrage USB mkusb, mais il peut exécuter les parties qui nécessitent des autorisations élevées sans graphiques.)

xhost et sudo -H

  1. Il existe une solution de contournement pour autoriser les programmes d'application graphiques appartenant à d'autres utilisateurs que l'utilisateur connecté dans Wayland.

    xhost +si:localuser:root
    
  2. gksuet gksudone sont pas fournis avec Ubuntu standard et ne fonctionnent pas ici, mais ils fonctionnent sous Xorg.

    Au lieu de cela, vous pouvez utiliser

    sudo -H
    
  3. C’est une bonne idée d’empêcher par la suite les programmes d’application graphiques appartenant à d’autres utilisateurs que l’utilisateur connecté,

    xhost -si:localuser:root
    

backend admin gvfs

Dans Ubuntu 17.10 (gvfs> = 1.29.4), vous pouvez utiliser le backend admin de gvfs. Notez que vous avez besoin du chemin complet.

gedit admin:///path/to/file

En théorie, la méthode backend de gvfs (qui utilise polkit) est meilleure et plus sûre (que xhostet xudo -H), quelle que soit l'interface utilisateur que vous utilisez.

Vous n'exécutez pas toute l'application en tant que root. L'escalade de privilèges ne se produit que lorsque cela est strictement nécessaire. Voir le lien suivant et les liens de celui-ci,

nautilus-admin

Il est également possible d'utiliser nautilus-admindes opérations de fichiers avec des autorisations élevées et geditavec des autorisations élevées. Ceci est décrit dans la réponse suivante à AskUbuntu,

Accès temporaire pour root au bureau Wayland via une fonction gks

S'il vous plaît éviter sudo GUI-program. Cela peut entraîner le remplacement par le système des fichiers de configuration correspondant à votre ID utilisateur habituel avec rootla configuration de s, ainsi que la définition de la propriété et des autorisations pour adapter rootet verrouiller votre ID utilisateur habituel. Vous devez exécuter des applications graphiques avec sudo -H, qui écrit les fichiers de configuration dans rootle répertoire de base de /root. Exemple:

sudo -H gedit myfile.txt

Mais il y a un risque que vous oubliez -H. Au lieu de cela, vous pouvez créer une fonction, par exemplegks

gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }

et stockez-le dans vos ~/.bashrcproches pseudonymes. Ensuite, vous pouvez courir

gks gedit myfile.txt

d'une manière similaire à celle utilisée gksudoauparavant.

Essai

Vous pouvez vérifier sudo, sudo -Het le gkstravail avec les commandes suivantes

sudodus@xenial32 ~ $ sudo bash -c "echo ~"
/home/sudodus
sudodus@xenial32 ~ $ sudo -H bash -c "echo ~"
/root
sudodus@xenial32 ~ $ gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }
sudodus@xenial32 ~ $ gks bash -c "echo ~"
localuser:root being added to access control list
/root
localuser:root being removed from access control list
sudodus@xenial32 ~ $ 

et bien sur

gks gedit myfile.txt

selon l'exemple de la section précédente.

Méthode fonctionnant via les menus Alt-F2 et Gnome Shell

Au lieu d’ajouter une simple fonction à une ligne ~/.bashrc, vous pouvez créer un système fonctionnant également sans bash. Il peut être pratique à utiliser, mais son installation est plus compliquée. Veuillez noter que vous ne devez installer qu'une seule des alternatives, car la fonction une ligne perturbera l'utilisation de ce système plus complexe.

Trois fichiers

Le shellscript gks:

#!/bin/bash

xhost +si:localuser:root

if [ $# -eq 0 ]
then
  xterm -T "gks console - enter command and password" \
  -fa default -fs 14 -geometry 60x4 \
  -e bash -c 'echo "gks lets you run command lines with GUI programs
with temporary elevated permissions in Wayland."; \
read -p "Enter command: " cmd; \
cmdfile=$(mktemp); echo "$cmd" > "$cmdfile"; \
sudo -H bash "$cmdfile"; rm "$cmdfile"'
else
 xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H "$@"
fi 

xhost -si:localuser:root;

Le fichier de bureau gks.desktop:

[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gks
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gks %f
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland

Le fichier d'icône gks.svgressemble à ceci:

entrez la description de l'image ici

Vous pouvez télécharger le fichier icône ou une archive contenant les trois fichiers à partir de ce lien,

wiki.ubuntu.com/Wayland/gks

Copiez les fichiers [extraits ou copiés et collés] aux emplacements suivants,

sudo cp gks /usr/bin
sudo cp gks.desktop /usr/share/applications/
sudo cp gks.svg /usr/share/icons

Déconnectez-vous / connectez-vous ou redémarrez, et une icône de bureau devrait apparaître. Cela fonctionnera à partir d'une fenêtre de terminal comme avec la solution simple avec la fonction.

Alt F2 boîte:

entrez la description de l'image ici

Menu Gnome Shell:

entrez la description de l'image ici

console gks et gparted:

entrez la description de l'image ici

Script personnalisé et fichier de bureau

Si vous ne disposez que de quelques applications graphiques nécessitant des autorisations élevées, vous pouvez créer des scripts et des fichiers de bureau personnalisés pour ces applications et éviter de saisir la commande (nom de l'application). Vous ne feriez que saisir le mot de passe, ce qui n’est pas plus difficile par rapport aux versions précédentes d’Ubuntu (vous devez quand même saisir le mot de passe).

Exemple avec le programme d'interface graphique simple xlogofourni avec le package de programme x11-apps:

Le shellscript gkslogo(simplifié par rapport à gks),

#!/bin/bash

xhost +si:localuser:root

xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H xlogo

xhost -si:localuser:root;

Le fichier de bureau gkslogo.desktop:

[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gkslogo
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gkslogo
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland

J'étais paresseux et utilisais le même fichier d'icônes gks.svg

Copiez les fichiers [copiés et collés] aux emplacements suivants,

sudo cp gkslogo /usr/bin
sudo cp gkslogo.desktop /usr/share/applications/

gks [logo] console et xlogo:

entrez la description de l'image ici


"L’accès temporaire de la racine au bureau Wayland via la fonction gks" est-il une méthode plus sûre (par exemple que l’ajout d’un fichier comme indiqué /etc/xdg/autostart/xhost.destopégalement), car elle permet de restaurer l’environnement original? Et pouvons-nous remplacer en toute sécurité sudo -Hpar gksudans l'alias afin d'utiliser l'insertion dans des fichiers .desktop, etc.?
Sadi

1
Oui, je pense qu'il est plus prudent d'autoriser l'accès root au bureau uniquement lorsque cela est nécessaire. Et oui, vous pouvez remplacer sudo -Hpar gksudans la fonction, cela peut fonctionner mieux pour vos applications.
sudodus

1
+1 pour une réponse extrêmement complète. Semblable à votre gksabréviation, j'avais configuré gsupour utiliser des kits de stratégie (le nouvel avenir pour 16.04) pour geditet nautilus. Quand 18.04 sera publié, je pense que je vais juste nommer le xhost +si...script de wrapper gksuque je n’installerai jamais à partir de paquets commençant par 18.04.
WinEunuuchs2Unix

2
"Wayland est conçu pour ne pas autoriser les autorisations élevées (sudo -H, gksu ...) avec les programmes d'application à interface graphique." -- faux. Wayland autorise parfaitement les applications root. Vous pouvez voir cela en courant sudo -E gedit. Il existe actuellement un bogue dans gdmlequel il configure le serveur de compatibilité Xwayland X11 pour ne pas prendre en charge XAUTHORITY, qui est requis pour que les applications X11 exécutées en tant que root fonctionnent. Les applications de waylands natives fonctionnant en tant que root fonctionnent parfaitement.
Psusi

1
@ psusi, j'ai modifié la réponse pour éviter les déclarations sur la conception et les intentions de Wayland.
sudodus

6

Mieux vaut vérifier si wayland fonctionne vraiment avant d'accorder le droit root

if [ $XDG_SESSION_TYPE = "wayland" ]; then
    xhost +si:localuser:root
fi

5

Si vous utilisez Ubuntu 17.04 ou une version ultérieure, il est recommandé d'utiliser le backend admin gvfs . Ajoutez simplement admin: // au début du chemin de fichier complet que vous souhaitez ouvrir dans une application telle que l' éditeur de texte ou les applications de fichiers .

Par exemple, pour modifier les paramètres de démarrage, ouvrez

admin:///etc/default/grub

Cette méthode utilise PolicyKit et fonctionnera toujours avec la valeur par défaut Wayland d'Ubuntu 17.10, contrairement à sudo et gksu pour les applications à interface graphique.


1
Merci. Pour moi, cela fonctionnait mieux avec gedit (sauf un comportement étrange quand on l'utilisait simplement gedit admin:), très curieusement avec nautile (presque inutile) et totalement échoué avec synaptique . Des idées?
Sadi

Cela ne fonctionnera pas avec synaptique. Cela devrait fonctionner correctement dans nautile cependant, mais vous devez choisir un répertoire qui ne ressemble pas à un fichieradmin:///etc/
Jeremy Bicha

Cela fonctionne un peu avec Nautile, mais vous verrez ce que je veux dire ("très curieusement", "presque inutile") même lorsque vous ouvrez directement un répertoire et que vous essayez de faire ceci ou cela ;-)
Sadi

@Sadi Je n'ai aucune idée de ce qu'est "ceci et cela". Vous pouvez créer un bogue si cela ne fonctionne pas correctement.
Jeremy Bicha

3

Pour les applications qui utilisent su-to-root et pkexec, vous pouvez ajouter ce code à /etc/xdg/autostart(voir mon commentaire sur le tableau de bord ) à vos risques et périls:

cat <<EOF | sudo tee /etc/xdg/autostart/xhost.desktop
[Desktop Entry]
Name=xhost
Comment=Fix graphical root applications
Exec="xhost +si:localuser:root"
Terminal=false
Type=Application
EOF

D'autres applications racine sont également interrompues sur Wayland (voir les bogues 1713313 et 1713311 ).


Si vous ne voulez pas de solution permanente, vous pouvez utiliser la méthode de @ ravery:

il suffit de taper xhost +si:localuser:rootle terminal avant de lancer l'application privilégiée


1

Si une application prend en charge l'API Wayland, vous pouvez l'exécuter en tant que root à l'aide de la sudo -EH applicationcommande.

Le commutateur -E indique à sudo de conserver les variables d’environnement (ainsi que WAYLAND_SOCKET et XDG_RUNTIME_DIR) nécessaires aux applications. Il est toujours préférable d’utiliser cette option par rapport au hack xhost méchant proposé dans d’autres réponses. xhost permet à l'application de s'exécuter sous un wrapper X, ce qui est moins sûr que d'utiliser Wayland (presse-papiers partagé, enregistrement au clavier, etc.). L'astuce sudo -EH ne fonctionnera pas avec une application qui n'a pas été réécrite pour Wayland, comme gparted par exemple, mais qui fonctionnerait avec gedit, etc.


0

En fait, le code suivant fonctionne presque:

#! /bin/bash
set -e 
if [ -z "$1" ] ; then
    echo "Application is not specified" ;  exit
fi 
if [ $XDG_SESSION_TYPE = "wayland" ]; then
    if [[ -t 1 ]]; then
       xhost +si:localuser:root
       sudo -u root "$@"
       xhost  -  
       exit 0
    fi 
fi
gksu "$@"

(Veuillez m'excuser pour le style naïf du code bash - je suis une sorte de débutant avec ce sujet). T ne fonctionne pas stable à partir de Alt-F2, si la dernière sélection n'était pas un terminal; dans ce cas, nous ne pouvons tout simplement pas définir le focus sur la boîte de dialogue du mot de passe On dirait que cela fonctionne dans le menu Gnome. Quoi qu'il en soit <1. ​​Ce n'est pas une solution à 100%. 2. Il me semble que les architectes Ubuntu pensent que nous ne sommes pas censés chercher de solution de rechange.


1
Je pense que vous voulez "$@"(au lieu de "$1" "$2" ...).
Muru

Oui bien sûr :-) Ce ne sont que des traces de mes expériences
Alex Chapiro
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.