Locking down a GNOME setting

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.

3 thoughts on “Locking down a GNOME setting

  1. You make it sound like the order that user-db and system-db appear in the /etc/dconf/profile/child is important.

    “Whatever database is on this first line will be used as the writable database. “user-db””

    “Because this is not on the first line it is not writable.”

    If the order matters, what’s the point of the user-db and system-db parts? E.g. why this:

    user-db:user
    system-db:child

    may as well be this:

    user
    child

    if it’s the order that matters. Surely this:

    user-db:user
    system-db:child

    should work the same as

    system-db:child
    user-db:user

    But you seem to be saying that is not the case.

  2. https://developer.gnome.org/dconf/unstable/dconf-overview.html
    says
    “The first line indicates the database used to write changes, and the remaining lines indicate read-only databases. (The first line should specify a user-db or service-db, so that users can actually make configuration changes.) ”

    Which I read as meaning the order does matter. But then

    https://wiki.gnome.org/Projects/dconf/SystemAdministrators
    says
    “For backward compatibility with previous versions of the dconf profile format, if lines do not have user-db: or system-db: specified, dconf will assume that the first line specifies a user database and the remaining lines specify system databases. ”

    Which I read as saying that the order did used to matter, but doesn’t now so long as you specify the user-db and system-db. Still makes sense to be consistent with order though I guess.

    I think the documentation could be clearer.

Leave a Reply

Your email address will not be published. Required fields are marked *