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

Question

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 du mot de passe est désactivée. Cela ressemble donc à un problème de création d’un tty pour root.

Aucun conseil?

Panther · Answer

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 Fedora bogue 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 ( buntu Devs Incertain sur l’utilisation de Wayland par défaut dans 17.10 - OMG! Ubunt ).

Rapport de bogue Ubuntu: Impossible de lancer des applications pkexec'ed sur une session Wayland

Contournement potentiel - Si vous modifiez des fichiers système avec un éditeur graphique (tel que gedit), utilisez un outil en ligne de commande tel que nano ou vim ou emacs. nano est généralement plus facile pour les nouveaux utilisateurs, vim est plus puissant et présente davantage de fonctionnalités, voir ce didacticiel Vim ou similaire.

Quoi qu'il en soit, si vous voulez vraiment ou devez exécuter des applications graphiques en tant qu'utilisateur root , définissez d'abord xhost, ce qui force 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 réparées avec xhost +si:localuser:root placé dans le démarrage 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 revenez-vous de Wayland à Xorg dans Ubuntu 17.10?

sudodus · Answer

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, synaptic et l'outil de partitionnement Gparted, gparted. J'utilise MakeUSB pour créer des lecteurs de démarrage USB mkusb également, mais il peut exécuter les parties nécessitant des autorisations élevées sans graphique.)

`xhost` et `Sudo -H`

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 
```
gksu et gksudo ne 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 
```
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 xhost et 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,

La réponse de sisco311 dans le fil de discussion des forums Ubuntu 'Quelle meilleure pratique pour utiliser gedit en tant que root?'

Ceci est le post # 4. Voir aussi l'article n ° 6 dans le même fil.

nautilus-admin

Il est également possible d'utiliser nautilus-admin pour les opérations sur les fichiers avec des autorisations élevées et d'utiliser gedit avec des autorisations élevées. Ceci est décrit dans la réponse suivante à AskUbuntu,

comment démarrer Nautilus en tant que root?

Accès temporaire de la racine au bureau Wayland via la fonction `gks`

S'il vous plaît éviter Sudo GUI-program. Cela peut amener le système à remplacer les fichiers de configuration de votre ID utilisateur habituel par la configuration de root, à définir la propriété et les autorisations de manière à correspondre à root et à verrouiller votre ID utilisateur habituel. Vous devez exécuter les applications graphiques avec Sudo -H, qui écrit les fichiers de configuration dans le répertoire de base de root, /root. Exemple:

Sudo -H gedit myfile.txt

Mais vous risquez d'oublier -H. À la place, vous pouvez créer une fonction, par exemple gks.

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

et stockez-le dans votre ~/.bashrc près des alias. Ensuite, vous pouvez courir

gks gedit myfile.txt

d'une manière similaire à la façon dont vous avez utilisé gksudo auparavant.

Essai

Vous pouvez vérifier comment Sudo, Sudo -H et gks fonctionnent 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 d’une seule 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 icône gks.svg ressemble à ceci:

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 case:

Menu Gnome Shell:

console gks et gparted:

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 elles 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 graphique simple xlogo fourni 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 icône 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:

eli chan · Answer

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

Jeremy Bicha · Answer

Si vous utilisez buntu 17.04 ou supérieur, il est recommandé d'utiliser le backend gvfs admin . 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 the Fichiers applications .

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.

N0rbert · Answer

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 bug 171331 et bug 1713311 ).

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

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

ZAB · Answer

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

L'option -E indique à Sudo de préserver 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.

Alex Chapiro · Answer

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 novice 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.