2

I want to ‘lockdown’ a particular key/value combination in dconf, so that only superusers will be able to modify that particular setting. In order to achieve this it is necessary to add a ‘lock’ to the system database, so that no equivalent key/value listed in a higher order database (in the dconf profile) can take precedence.

For a detailed explanation of the concept of a dconf profile and the related ‘key files’ please see the Gnome System Administrators Wiki.

From the System Admin Wiki:

Lockdown is supported by creating a 'locks' subdirectory in the key file directory (ie: /etc/dconf/db/local.d/locks). The files contained in this directory contain a list of keys to lock, one per line.

My keyfile directory shows as ‘ibus.d’, as opposed to ‘local.d’ given in the example:

:/etc/dconf/db/ibus.d$

By checking the dconf profile /etc/dconf/profile/ibus, this would appear correct:

Contents of 'ibus' file: user-db:user \ system-db:ibus

As per the Wiki:

  1. Create an appropriate key file:

    ==> /etc/dconf/db/ibus.d/00-media-handling ==<

    [org/gnome/desktop/media-handling]

    automount=false

  2. Create a ‘locks’ subdirectory and add an appropriate file:

    ==> /etc/dconf/db/ibus.d/locks/00_media-handling-lock ==<

    /org/gnome/desktop/media-handling/automount

In my case I have set, and locked, the automount key, for the org.gnome.desktop.media-handling schema, to 'false'.

Finally run sudo dconf update. For good measure I also reboot the machine.

The expected behaviour, upon attaching a USB drive, would be for the device not to automount. This, however, is not the case. If I attach a USB drive and run df:

/dev/sdb1 983344 192 983152 1% /media/user/xxxx-xxxx

Assuming I am at fault; I have started from ‘scratch’ numerous times, each time following the (identical) instructions from varied sources, including examples given on this site; example one and two. Each time to no avail. Please could you kindly enlighten as to where I could be going wrong? (Ubuntu 16.04)

  • 1
    I've never seen that work properly in Ubuntu, ever. – doug May 19 '18 at 19:53
  • @doug thank you. I honestly cannot see what I am doing wrong, and I have read numerous articles and started afresh numerous times. If this does not work, should it not be reported as a bug? – Andrew Hardiman May 20 '18 at 15:25
  • 1
    I think I did a couple of years ago, I'll have a look in LP. As I remember I tried every which way I could find, had absolutely no effect.. – doug May 20 '18 at 19:09
  • Can't find, either I didn't or it was closed for inactivity, was a couple of years ago. If you file add link here. ( note that bugs are best filed on development version though you could file on bionic, tag cosmic. – doug May 20 '18 at 19:14
  • 1
    Take a look here, https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1122028 & here, https://bugzilla.gnome.org/show_bug.cgi?id=693149 Maybe something to help you?? – doug May 20 '18 at 19:19
  • @doug thanks for looking. I've spent an inordinate amount of time trying to get this to work, very frustrating. If I report as a bug, I'll be sure to update. Thanks again. – Andrew Hardiman May 20 '18 at 19:30

1 Answers1

1

The profile file must be /etc/dconf/profile/user

From man 7 dconf:

On startup, dconf consults the DCONF_PROFILE environment variable.
If set, dconf will attempt to open the named profile, aborting if that fails.
If the environment variable is not set, it will attempt to open the profile named "user"
and if that fails, it will fall back to an internal hard-wired configuration.

I've added that file:

cat /etc/dconf/profile/user
user-db:user
system-db:local

Then I've put my lockdown file in /etc/dconf/db/local.d/lock

And finally I run dconf update

I had to logout and login again as I was using the hard-wired configuration. Now it works.

  • Thank you. However, I cannot follow this through to any meaningful outcome. Which key/value combination did you lock, in order to test that your method was implemented successfully? I'm specifically interested in finding a way of locking the automount key to a value of false, in a global fashion, to prevent all but superuser access to externally attached media (in this case USB drives); the automount key is related to the org.gnome.desktop.media-handling schema. – Andrew Hardiman Jul 03 '18 at 15:07
  • Could you lock that key? – Eduardo Villanueva Che Jul 05 '18 at 10:37
  • When you lock a key you'll use it's default value so to lock and modify the key you'd need to modify its default value. Try adding a file like /usr/share/glib-2.0/schemas/my-defaults.gschema.override: [org.gnome.desktop.media-handling] automount=0

    Then run: glib-compile-schemas --strict /usr/share/glib-2.0/schemas/

    That will change the default value.

    I was locking the proxy settings down: /system/proxy/mode /system/proxy/autoconfig-url

    – Eduardo Villanueva Che Jul 05 '18 at 10:44