For what it's worth, I consider gdm's usage of dconf to be improper.

That said, I'm not totally convinced that /etc is exactly the correct place for dconf databases either.  There is a certain '/var'ness about them...

Created attachment 219173 [details] [review]
Configure the system database path through environment

Update to apply to 0.13.4

Review of attachment 219173 [details] [review]:

::: dconf-0.13.4.orig/engine/dconf-engine-profile.c
@@ +196,3 @@
+      if (dconf_dir == NULL)
+        dconf_dir = "/etc/dconf";
+      gchar *filename = g_build_filename (dconf_dir, "profile", profile, NULL);

This doesn't seem to deal with the profile == NULL case, which is still hard-coded to /etc/dconf?

Created attachment 227163 [details] [review]
updated version of the patch for comment

I believe this addresses my comment above?

I think I'm going to introduce a new database type: file-db, used like so:

file-db:/usr/share/whatever

This will specify a gvdb to use as a read-only database, with no support for writes or change notification.

It's already supported to use an absolute pathname for DCONF_PROFILE.


This means that we could have dconf profiles in /usr/share pointing at read-only dconf databases in /usr/share.

Bug 672303 would easily allow the database to be compiled as part of gdm's build process, removing need for 'dconf update' (although gdm used to have a hack to do exactly this even without official support).

One small detail might derail this party, depending on how multiarch works on your distro: a dconf database written by any system can be read by any system, but the internal byte order is according to the system that wrote it.  gvdb and GVariant themselves are always little-endian, but the data stored in multi-byte numberic formats (int32s, doubles, etc.) are swapped.  As such, big-endian systems will 'compile' the database differently than little endian systems (although both will be able to read it).

That could either be fixed by having the keyfile->db compilation tool able to specify the output byte order or by just dropping support for writing big-endian dconf databases entirely.

This would work nicely too. I just worked around that problem in the way that required the least effort.

As for byte-swapping issues: as long as all machines are able to read the gvdb database, I don’t think it matters much – unless there is a big performance overhead, but I don’t think so given the amount of data.

(In reply to comment #6)
> As for byte-swapping issues: as long as all machines are able to read the gvdb
> database, I don’t think it matters much – unless there is a big performance
> overhead, but I don’t think so given the amount of data.

It only matters if you want the gvdb database to be in a non-architecture-qualified path (/usr/share, /etc or /var) that is in an architecture-dependent package (Architecture: any) that can be co-installed for more than one architecture (Multi-Arch: same). If that's the case, it has to be byte-for-byte identical on each architecture that ships it.

If the gvdb database "goes with" a public shared library - for instance if GLib, GIO or Gtk shipped a gvdb database for whatever reason - then that might be a problem; but in gdm's case I think it would go in the gdm3 binary package, which isn't Multi-Arch anyway, because you can only have one /usr/sbin/gdm3?

Even though I think it's weird how gdm is using dconf right now, I think one thing about it that is vaguely nice is that the user can make actual configuration changes to gdm (like adding a login banner) via /etc/dconf/db/gdm.d/.  This is actual configuration, and it makes the use of an alternate dconf profile at least a vaguely useful concept.

Ideally these sort of one-off things would be stored at some gdm-specific path in a global system-level database...

There would still be the question of how the user should specify a font or a theme or a default background image (for example) for the login screen, however.  These are settings read by ordinary system components, so the situation here is less clear other than to modify the gdm user's dconf database directly, which is a bit odd -- so again, profiles could make some sense for that.


Looking forward to fixing that, I think that I want to do the following:

 - make a system dconf service, running as user 'dconf'

 - make a /var/lib/dconf/db directory, writable by the dconf user and sticky

 - modify dconf to read profiles from /usr/share/dconf/profile if they are not
   found in /etc/dconf/profile.  gdm would install its profile here.

 - modify dconf to read system dbs from /var/lib/dconf/db in preference to
   the files that are now in /etc/dconf/db

 - modify dconf-update to write to /var/lib/dconf/db.  the plan would be to
   run this as root, so the databases written via dconf-update could not be
   modified by the dconf daemon (remember: directory is sticky)

 - modify dconf-update to read from /usr/share/dconf/db/*.d in addition to
   the files in /etc/dconf/db/*.d.  gdm would install to this path.

 - binaries in /etc/dconf/db are now deprecated (but user-created .d
   directories continue to be here for dconf-update)

 - unless the user creates it, /etc/dconf now no longer exists (bliss)

 - writes to the system-level dconf service (gated by polkit) go to files in
   /var/lib/dconf/db so we don't get the weird feeling of a service writing
   binary state files to /etc


Does this plan fully address your concerns in filing this bug?

I think this would work, although I’m not sure I understand what would happen when you try to change a setting from the gdm session.

The first question being, do we *want* the user to be able to configure something from the session, and as for me the answer is no. This is why the Debian gdm package generates the dconf configuration from a key-value file (easy to configure for the sysadmin), and takes every step to ensure these settings can’t be modified from the session.

Your proposal doesn’t address how the sysadmin can manage the configuration. If we move it to /var entirely and entirely in binary format, the problem bites back in the sense that there is a configuration which is *not* in /etc, which in turn can be a problem for e.g. backups.

I propose that there would be two types of system-level dconf databases.

First is those maintained as in the current system and based on keyfiles in /etc/dconf/db/*.d/; dconf-update would simply write the binary file to /var/lib instead of /etc.

Second is those that are entirely represented by binary data in /var/lib and updated via GSettings.

The gdm session would _not_ be able to modify its settings but system administration tools could modify pure-/var/lib settings databases via a D-Bus API with polkit checking.

(In reply to comment #9)
> back in the sense that there is a configuration which is *not* in /etc, which
> in turn can be a problem for e.g. backups.

Another interesting possibility: the dconf service could write a keyfile to /etc and compile to /var/lib.  This way, the tools and the service could be used interchangeably.

It's difficult to think about how this might work in the presence of multiple files in the .d directory, however...

(In reply to comment #11)
> Another interesting possibility: the dconf service could write a keyfile to
> /etc and compile to /var/lib.  This way, the tools and the service could be
> used interchangeably.

I’m not sure how feasible that is, but it would definitely make the most sense in terms of FHS usage, ease of use and features.

Comment on attachment 219173 [details] [review]
Configure the system database path through environment

Working on a different approach.

Comment on attachment 227163 [details] [review]
updated version of the patch for comment

Working on a different approach.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dconf/issues/7.