web-dev-qa-db-fra.com

Comment exécuter gsettings pour un autre utilisateur Ubuntu 18.04.2 LTS

J'essaie d'exécuter gsettings pour un autre utilisateur dans Ubuntu 18.04.2 LTS. Plus précisément, j'essaie d'empêcher l'écran de l'utilisateur de se verrouiller. Cela sera exécuté dans le cadre d'un script bash. Les commandes que j'utilise sont:

su someuser
dbus-launch gsettings set org.gnome.desktop.screensaver lock-enabled false

Parce que cela est exécuté via ssh, j'ouvre avec dbus-launch pour démarrer dbus puis j'essaye un simple appel à gsettings. Cependant, j'obtiens l'erreur:

dbus[22652]: Unable to set up transient service directory: XDG_RUNTIME_DIR "/run/user/1000" is owned by uid 1000, not our uid 1001

(process:22650): dconf-CRITICAL **: 11:11:27.830: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(process:22650): dconf-CRITICAL **: 11:11:27.830: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(process:22650): dconf-CRITICAL **: 11:11:27.836: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

Pour confirmer que les UID ne correspondent pas, j'ai vérifié le répertoire/run/user:

ls -lah /run/user

Quelles sorties:

total 0
drwxr-xr-x  4 root      root       80 Apr 16 14:25 .
drwxr-xr-x 31 root      root      900 Apr 16 14:25 ..
drwx------  4 adminuser adminuser 100 Apr 16 14:25 1000
drwx------ 11 someuser  someuser  260 Apr 16 12:26 1001

J'ai également essayé d'utiliser Sudo:

Sudo -u "someuser" dbus-launch gsettings set org.gnome.desktop.screensaver lock-enabled false

Ce qui donne les erreurs:

(process:22264): dconf-CRITICAL **: 14:33:41.124: unable to create directory '/home/adminuser/.cache/dconf': Permission denied.  dconf will not work properly.

(process:22264): dconf-CRITICAL **: 14:33:41.124: unable to create directory '/home/adminuser/.cache/dconf': Permission denied.  dconf will not work properly.

(process:22264): dconf-CRITICAL **: 14:33:41.135: unable to create directory '/home/adminuser/.cache/dconf': Permission denied.  dconf will not work properly.

(process:22264): dconf-WARNING **: 14:33:41.152: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code2: Cannot open dconf database: Failed to open file “/home/adminuser/.config/dconf/user”: Permission denied

Ce qui conduit à la question, pourquoi gsettings essaie-t-il de s'exécuter pour adminuser au lieu de someuser et comment peut-il être dirigé pour s'exécuter pour someuser par adminuser sur SSH?

command-linegsettings
5
user2395126

Le problème ici est lié à Pourquoi les utilisateurs ne devraient-ils jamais utiliser Sudo normal pour démarrer des applications graphiques? c'est-à-dire que par défaut, Sudo ne change pas $HOME à celui de l'utilisateur cible.

Vous pouvez changer cela en utilisant le -H (--set-home) option:

 -H, --set-home
             Request that the security policy set the HOME environment
             variable to the home directory specified by the target user's
             password database entry.  Depending on the policy, this may
             be the default behavior.

Donc

Sudo -Hu someuser dbus-launch gsettings set org.gnome.desktop.screensaver lock-enabled false
5
steeldriver