I think the dconf documentation and GNOME’s Sysadmin lockdown documentation (There’s this GNOME dconf wiki page too) could be clearer as well as being less duplicated and scattered. I’ve started trying to improve those documents directly.

In the meantime, here are some simple instructions for locking down some settings in GNOME 3 so the user cannot change them. Thanks to Ryan for explaining this to me. I’d welcome anyone’s extra corrections.

In this example, two children, Alice and Bobby, have user accounts on the computer called “alice” and “bobby”, and I want their accounts, and only their accounts, to not allow changing the list of application launchers in gnome-shell’s Dash, and not allow changing the desktop background. (Just as an example.)

Creating a dconf profile

I create a dconf profile for children in /etc/dconf/profile/, like so:

$ sudo nano /etc/dconf/profile/child

And I put this text in that file:

user-db:user
system-db:child

That tells dconf to use the “user database” named “user” as the writable store of settings for this dconf profile. Whatever database is on this first line will be used as the writable database. “user-db” (user database) just means that dconf should look in XDG_CONFIG_HOME/dconf for this database. That typically means ~/.config/dconf/, so this is specific to the user. This is what dconf uses by default if you haven’t assigned a dconf profile or changed the default “user” profile.

This example additionally tells dconf to use our “system database” named “child” for this dconf profile. Because this is not on the first line it is not writable. Because it’s a “system database” it will be in a shared location – typically /etc/dconf/db/. So this is a good place to specify some locks to prevent changes in the “user database” by anyone with this “child” profile. We could also use this “system database” to set some default values for the “child” profile.

The dconf overview documentation explains that profile file format more fully.

Creating a dconf lock file

Then I create a lock file for that “child” system database, like so, though the actual filename doesn’t matter:

$ sudo mkdir /etc/dconf/db/child.d
$ sudo nano /etc/dconf/db/child.d/locks/00_some_locks

I put this text in that lock file:

/org/gnome/desktop/background/picture-uri
/org/gnome/shell/favorite-apps

I then call “dconf update” to tell it about the new profile and the lock file:

$ sudo dconf update

However, when you change the lock file, you’ll often need to do this too to make “dconf update” notice (see dconf  bug #741437):

$ sudo touch /etc/dconf/profile/child.d/locks
$ sudo dconf update

Using the dconf profile

Then I assign that dconf profile to the children’s user accounts, for instance by setting the DCONF_PROFILE environment variable in Alice’s .profile file:

$ sudo mkdir /home/alice/.profile

like so:

export DCONF_PROFILE="child"

If the child is already logged in then she’ll need to log out again to make her account use the new dconf profile. Also, don’t be foolish like me and put that in the .bash_rc file instead. That way lies confusion.

Note that the Alice can change her DCONF_PROFILE by changing that .profile file, to avoid the locks in her current profile. Or she can add a .bash_profile file to override .profile, or do something else clever. Locking of dconf settings is only for convenience – it isn’t meant to provide security. So if the user knows how to change her DCONF_PROFILE, she should probably be allowed to.

It would be nice if there was some GUI for managing profiles, and the databases’ locks, and default values. That seem doable.

I also wonder if there could be any API for applications to ask for admin access before making changes. Then a parent could, for instance, add just a single application launcher to the Dash. But I guess that would need us to either remove the dconf profile from the user (which needs a logout and login) or would need us to remove the lock from the dconf profiles’ system database, which would briefly unlock the setting for all other users who have the same dconf profile.