Lorsque vous utilisez Sudo
pouvoirs et appels gedit
, le menu de niveau supérieur avec File Edit View Search Tools Documents Help
est manquant.
Si je crée un ID utilisateur root et que je me connecte une fois et appelle gedit
créera-t-il les fichiers de configuration utilisateur nécessaires qui pourrait résoudre ce problème?
Est-ce que cela fera également disparaître les messages d'erreur ennuyeux chaque fois que j'utilise Sudo
, gksu
ou pkexec
en tant qu'utilisateur ordinaire avec des privilèges élevés àgedit
?
Y aura-t-il d'autres avantages avec Nautilus et d'autres applications Ubuntu dérivées de Gnome?
REMARQUE: par Sudo
vous permet de rechercher Google pkexec gedit
3,5k hits, gksu gedit
40k hits ou Sudo gedit
500k hits. Je suis dans la minorité en utilisant la première méthode mais je crois que cela deviendra la norme dans Ubuntu 17.04.
Mise à jour du 12 juin 2017 Voici une liste des erreurs que vous obtenez en utilisant pkexec gedit
:
(gedit:13003): Gtk-WARNING **: Calling Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-spell-enabled not supported
** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-encoding not supported
** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-position not supported
Sur ce rapport de bogue , il y a un engagement de corriger ces messages gênants à partir du 5 juin 2017. Aucune indication n'est donnée pour savoir quand le correctif sera en amont ni si la fonctionnalité sera implémentée ou si les messages d'erreur tout simplement disparaître.
Notez que le rapport de bogue a été déposé il y a plus d'un an et qu'au cours de cette période, il ne concerne que 18 personnes.
Encore une fois, avec sentiment. NE PAS UTILISER D'APPLICATIONS GRAPHIQUES RACINE!
Il existe à présent quelques exceptions à la règle ci-dessus. Par exemple, toute partie du panneau de configuration Ubuntu qui demande root est généralement sécurisée, mais uniquement parce qu'elle conserve les privilèges aussi longtemps que nécessaire, auquel cas elle les rétablit immédiatement en mode normal. De même, ils sont également spécialement conçus pour utiliser root
efficacement et de manière à ne pas casser les objets. En bref, tout ce que gedit
et la plupart des autres applications ne font pas.
Si vous avez vraiment besoin de gedit
pour avoir sa propre configuration dans le dossier /root
, lancez-la comme suit:
Sudo -i gedit
Cependant, ceci encore ne fonctionnera pas pour un certain nombre de raisons. La disparition de votre barre de menu est plus ou moins un effet secondaire du fonctionnement du système de menus de Ayatana . En bref, le système essaie de créer des objets de menu pour/appartenant à l'utilisateur root
, ce qui entraîne une rupture décisive.
Vous pouvez contourner le manque de menu en utilisant le drapeau -E
de Sudo
, mais cela causera tout de même l'ennui de DBus/DConf /. Dans ce mode, le menu sera directement intégré à la fenêtre de gedit
, car nous ne pouvons toujours pas obtenir de lien vers DBus/Ayatana.
Cela fait écho au sentiment des développeurs Ubuntu et est not a bug. Ils sont d’avis que l’interface graphique est effectivement "en mode facile" et que root
accès est effectivement pas "en mode facile". Si vous voulez root
, allez au terminal et utilisez-le. En fait, il s’agit plutôt d’une forme de résistance valable. Si vous ne pouvez pas utiliser nano
pour éditer des fichiers, vous ne devriez pas fouiller en tant qu’utilisateur root
.
Si vous devez absolument utiliser root
sous l'interface graphique (que je conseille fortement vous ne le ferez pas, même en tant que son propre utilisateur), créez un fichier nommé /etc/lightdm/lightdm.conf
et mettez-le dans ce fichier:
[SeatDefaults]
greeter-show-manual-login=true
Redémarrez le service lightdm
en utilisant Sudo systemctl restart lightdm.service
et vous devriez pouvoir vous connecter en tant que root
. Si vous n'utilisez pas lightdm
, recherchez et suivez les instructions propres à ce gestionnaire d'affichage.
Vous devrez également réactiver le compte root, ce que vous pouvez faire en exécutant simplement la commande suivante:
Sudo passwd root
Assurez-vous de choisir un mot de passe très fort, car ce sera autorisera les connexions root sur votre système. Notez que ceci est aussi contre toutes les recommandations car Sudo
existe et est beaucoup plus sûr/moins susceptible de vous laisser accidentellement casser quelque chose.
Sur cette note, lorsque vous effectuez cette opération, gedit
fonctionnera en tant que root (comme vous le souhaitez) dans la session utilisateur root
. Cependant, à la seconde où vous revenez à votre session principale, il refusera toujours de travailler (pour les raisons énumérées ci-dessus).
Le compte root
ne doit pas être utilisé pour contourner l'erreur Permission denied
tant-détestée _ que bon gré mal gré. Pensez à ce message comme suit:
Hé, ce que vous faites pourrait avoir de graves effets secondaires sur votre système. Réfléchissez bien et vérifiez bien votre commande pour vous assurer que vous faites exactement ce que vous avez l'intention de faire. Si vous êtes certain que c'est ce que vous voulez faire, augmentez le niveau de privilège le plus bas possible pour pouvoir faire ce que vous voulez.
Malgré cela, voyez s'il existe une solution qui n'implique pas de passer à un compte privilégié. Il est beaucoup plus facile de supprimer et de recréer un utilisateur endommagé que de recréer un système endommagé.
J'ai fini par renoncer à root/Sudo ayant sa propre configuration pour gedit
. J'ai également abandonné pkexec
en remplaçant gksu
et j'ai utilisé Sudo -H
à la place. J'ai ensuite créé un script pour "emprunter" la configuration de l'utilisateur actuel à initialiser:
gedit
paramètres de configuration possiblesSans plus tarder, voici le script:
#!/bin/bash
# NAME: sgedit
# PATH: /mnt/e/bin
# DESC: Run gedit as Sudo using $USER preferences
# DATE: June 17, 2018.
# Must not prefix with Sudo when calling script
if [[ $(id -u) == 0 ]]; then
zenity --error --text "You cannot call this script using Sudo. Aborting."
exit 99
fi
# Get user preferences before elevating to Sudo
gsettings list-recursively | grep -i gedit | grep -v history | \
grep -v docinfo | \
grep -v virtual-root | grep -v state.window > /tmp/gedit.gsettings
sudoFunc () {
# Must be running as Sudo
if [[ $(id -u) != 0 ]]; then
zenity --error --text "Sudo password authentication failed. Aborting."
exit 99
fi
# Get Sudo's gedit preferences
gsettings list-recursively | grep -i gedit | grep -v history | \
grep -v docinfo | \
grep -v virtual-root | grep -v state.window > /tmp/gedit.gsettings.root
diff /tmp/gedit.gsettings.root /tmp/gedit.gsettings | grep '>' > /tmp/gedit.gsettings.diff
sed -i 's/>/gsettings set/g; s/uint32 //g' /tmp/gedit.gsettings.diff
chmod +x /tmp/gedit.gsettings.diff
bash -x /tmp/gedit.gsettings.diff # Display override setting to terminal
Nohup gedit -g 1300x840+1+1220 $@ &>/dev/null &
# Set the X geometry window size (WIDTHxHEIGHT+X+Y).
}
FUNC=$(declare -f sudoFunc)
Sudo -H bash -c "$FUNC; sudoFunc $*;"
exit 0
Sudo
mais utilisez sgedit /path/to/root-owned-file
gedit
GUI séparée ouverte.1300x840+1+1220
dans la configuration de votre moniteur. Moniteur "normal" unique ressemblerait à quelque chose comme 700x400+0+0