Running gsettings as root

[Josef Wolf]

Hello,

I want to do lots of configuration settings as root in the background

I know, I can do this with


sudo -u $USER dbus-launch --exit-with-session gsettings set [ .... ]


This works fine while the user is NOT logged in.

But it won't work if the user IS logged in.

I need a command that works independently of whether the user is logged in or
not.

Any suggestions?

[Karl Auer]

Post by Josef Wolf
I want to do lots of configuration settings as root in the background
 [...]
I need a command that works independently of whether the user is
logged in or not.

You could run your scripts setuid, though setuid scripts are dangerous
- make very sure they are not editable by anyone but root, and make
sure that the commands they execute are not subvertible, and use full
paths to every executable they call.

You could run your scripts from the system crontab, which allows the
user to be specified. This would be my preference, especially if they
are to be run regularly.

A script (with the right permissions) placed in one of the /etc/cron.*
directories will be run at those intervals. So you can put (copy of) a
script there, then take it out (or have it delete itself) after it has
run.

You could run your scripts as startup scripts (systemd).

Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (***@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

[Josef Wolf]

Post by Karl Auer

Post by Josef Wolf
I want to do lots of configuration settings as root in the background
 [...]
I need a command that works independently of whether the user is
logged in or not.

You could run your scripts from the system crontab,

This is actually what I do.

But the problem is NOT to run the scripts as the specified user.

The problem is that they won't work while the user is logged in because
dbus-launch starts a new dbus-instance and the changes done by gsettings will
be discarded as soon as dbus-launch exits.

[Karl Auer]

Post by Josef Wolf

Post by Karl Auer
You could run your scripts from the system crontab,

This is actually what I do.
But the problem is NOT to run the scripts as the specified user.

Maybe you misunderstand - the system crontab runs jobs as root AND can
run jobs as any other specified user. So jobs run from the system
crontab can be run as root regardless of whether some other user is
logged in or not.

Post by Josef Wolf
The problem is that they won't work while the user is logged in
because dbus-launch starts a new dbus-instance and the changes done
by gsettings will be discarded as soon as dbus-launch exits.

I have no idea why that is relevant. I'm not saying it is not relevant,
just that I don't understand why it would be. Why is that relevant?

Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (***@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

[Josef Wolf]

Post by Karl Auer

Post by Josef Wolf

Post by Karl Auer
You could run your scripts from the system crontab,

This is actually what I do.
But the problem is NOT to run the scripts as the specified user.

Maybe you misunderstand - the system crontab runs jobs as root AND can
run jobs as any other specified user.

I know. And myself thinks, you mis-understand ;-)

The commands are executed with proper values for uid/gid and $HOME setting. As
I wrote, setting up the user's environment is NOT the problem.

Besides: setting up the user's environment would not depend on whether the
user is already logged in or not.

Post by Karl Auer

Post by Josef Wolf
The problem is that they won't work while the user is logged in
because dbus-launch starts a new dbus-instance and the changes done
by gsettings will be discarded as soon as dbus-launch exits.

I have no idea why that is relevant. I'm not saying it is not relevant,
just that I don't understand why it would be. Why is that relevant?

dbus-launch is run as the proper target user, with the proper value of the
$HOME variable.

When the user is already logged in into the desktop at the time my script
runs, he will already have a dbus instance running. The dbus-launch instance
that is started by my script will notice the fact that there is already a dbus
instance running and start a NEW dbus instance. But the changes that gsettings
makes to this second dbus instance won't be written to the users dbus
database. The effect is that those changes won't have any effect.

[Karl Auer]

Post by Josef Wolf
I know. And myself thinks, you mis-understand ;-)

Why did you not explain the dbus constraints in your first email?

Your first email *appeared* to be all about getting commands working as
root without sudo or a user to run it. I gave you several ways to do
that.

In fact, your question was all about dbus.

Not giving a complete picture, then correcting us when we get the
answers "wrong", is very annoying.

Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (***@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

[Dave Howorth]

Post by Karl Auer

Post by Josef Wolf
I know. And myself thinks, you mis-understand ;-)

Why did you not explain the dbus constraints in your first email?

The dbus constraint was pretty self-evident right there in the middle of
the first email. It was certainly clear to me what the issue was. I just
didn't know the answer.

Post by Karl Auer
Your first email *appeared* to be all about getting commands working as
root without sudo or a user to run it. I gave you several ways to do
that.
In fact, your question was all about dbus.
Not giving a complete picture, then correcting us when we get the
answers "wrong", is very annoying.

The picture was right there in front of you, had you recognized it, so I
don't think Josef has anything to apologize for. Neither is there any
reason for you to get upset.

Just chill out. :)
Cheers, Dave

Post by Karl Auer
Regards, K.

[Oliver Grawert]

hi,

Post by Josef Wolf
Hello,
I want to do lots of configuration settings as root in the background
I know, I can do this with
   sudo -u $USER dbus-launch --exit-with-session gsettings set [ ....
]
This works fine while the user is NOT logged in.
But it won't work if the user IS logged in.
 

have a look at the dconf command (dconf-cli package), IIRC dbus will
check if there is a gsettings-daemon running and block if there is one
(to prevent concurrent access to the same key) ... 

dconf can modify the db directly without involving the daemon.

example:
sudo -u $USER "dconf write /org/gnome/gnome-session/auto-save-session
true"

ciao
oli

[Josef Wolf]

Post by Oliver Grawert

Post by Josef Wolf
I want to do lots of configuration settings as root in the background
I know, I can do this with
sudo -u $USER dbus-launch --exit-with-session gsettings set [ .... ]
This works fine while the user is NOT logged in.
But it won't work if the user IS logged in.

have a look at the dconf command (dconf-cli package), IIRC dbus will
check if there is a gsettings-daemon running and block if there is one
(to prevent concurrent access to the same key) ... 
dconf can modify the db directly without involving the daemon.

Are you sure about this? The dconf man page says:

Note that dconf needs a D-Bus session bus connection to write changes
to the dconf database.

And IF it can directly write: istn't there a risk to corrupt the database when
accessing it directly while it is opened by another process?

Or will dconf automatically use the existing connection when a user is logged
in and otherwise create a new one?

gsettings has the additional benefit that it will do type and consistency
checks.

[Karl Auer]

Post by Josef Wolf
gsettings has the additional benefit that it will do type and
consistency checks.

One method that might do an end run around all these dbus difficulties
would be to make the changes as the user, from within the user's
environment, automatically.

For example, generate a script to make the appropriate changes, and
place it in the user's startup sequence. Or run it from the user's
crontab. Or add it to the user's X startup script. Or any of a dozen
different other ways.

Just a thought.

Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (***@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

[Oliver Grawert]

hi,

Post by Oliver Grawert

Post by Josef Wolf
I want to do lots of configuration settings as root in the
background
I know, I can do this with
  sudo -u $USER dbus-launch --exit-with-session gsettings set [
.... ]
This works fine while the user is NOT logged in.
But it won't work if the user IS logged in.

have a look at the dconf command (dconf-cli package), IIRC dbus will
check if there is a gsettings-daemon running and block if there is one
(to prevent concurrent access to the same key) ... 
dconf can modify the db directly without involving the daemon.

  Note that dconf needs a D-Bus session bus connection to write
changes
  to the dconf database.

hmm, you are right ... the check is in the tool itself and both use
dbus ... 
nontheless, dbus-launch is definitely the wrong way since that spawns a
dbus daemon with a new session ID but what you want is to connect to
the running session bus in case the user is logged in ...

so use dconf directly, but make sure the right session ID is in your
environment ... i fear you need a slightly bigger script for that, the
session ID is stored in: /run/user/$UID/dbus-session ... you can source
that file and then just export DBUS_SESSION_BUS_ADDRESS, when you then
call dconf it will attach to the running session bus ... if
/run/user/$UID/dbus-session does not exist you fall back to use dbus-
launch to actually create a fresh session (since the user is not logged
in of that file doesnt exist)

here is a script snippet that we use on the phone images to do
something similar:

***@ubuntu-phablet:~$ cat /etc/profile.d/dbus-source.sh 
# source dbus address from new location
[ -e $XDG_RUNTIME_DIR/dbus-session ] && . $XDG_RUNTIME_DIR/dbus-session
[ -n "$DBUS_SESSION_BUS_ADDRESS" ] && export DBUS_SESSION_BUS_ADDRESS

(note that XDG_RUNTIME_DIR translates to /run/user/$UID ... but you
will likely not have it set when you run from "sudo -u $USER", so you
need to obtain the UID somewhere else and use the full path)

ciao
oli