[Bug 2072586] Re: Running "dconf update" with different umask affects the permissions of dconf databases in /etc/dconf/db/

Fri Apr 25 20:50:44 UTC 2025

** Description changed:

+ [ Impact ]
+ 
+ This was originally reported by a user applying the DISA-STIG on Ubuntu
+ desktop [1], which requires a global umask of 077. The global dconf databases
+ in /etc/dconf/db are intended to be read by many users (mode 644).
+ 
+ dconf uses g_file_set_contents from GLib to guarantee consistent writes [2][3].
+ The function creates a tempfile to rename over the original but does not
+ guarantee that the permissions of the tempfile to be the same as the original [4].
+ With umask 077, this causes a dconf database write to change the permissions of
+ the db file from 644 to 600.
+ 
+ This behavior was changed upstream in 45a36e52 to guarantee that the mode of the
+ original file is preserved [5].
+ 
+ The SRU of upstream 45a36e52 to Jammy+ will enable users to modify global GNOME
+ configuration without losing read access to the changed dconf databases.
+ 
+ [1] https://ubuntu.com/security/certifications/docs/disa-stig
+ [2] https://git.launchpad.net/ubuntu/+source/dconf/tree/gvdb/gvdb-builder.c?h=ubuntu/jammy#n518
+ [3] https://docs.gtk.org/glib/func.file_set_contents.html
+ [4] https://docs.gtk.org/glib/func.file_set_contents_full.html#description
+ [5] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4607
+ 
  [ Test Plan ]

+ Ensure that the patch resolves the original bug:
  ```
  sudo apt-get install dconf-cli
  mkdir -p /etc/dconf/db/database.d
  cat >/etc/dconf/db/database.d/test <<EOF
  [test]
  hello='world'
  EOF
  dconf update
  ls -la /etc/dconf/db/database
  umask 0077
  dconf update
  ls -la /etc/dconf/db/database
  ```

- The mode of `/etc/dconf/db/database` should be 0644 after the second
- `dconf update`.
+ Expected result:
+ -rw-r--r-- 1 root root 152 Apr 24 14:16 /etc/dconf/db/database
+ 
+ Observed result:
+ -rw------- 1 root root 152 Apr 24 14:16 /etc/dconf/db/database
+ 
+ [ Where problems could occur ]
+ 
+ GLib is depended upon by thousands of packages in Ubuntu (rdepends counts 3557
+ in Jammy). It's unknown how many of these packages call g_file_set_contents{,_full}.
+ 
+  * If
+     * a file was originally created with a more restrictive mode than the umask
+     * g_file_set_contents{,_full} is used to re-write the file
+     * a user with less permissions than needed to r/w/x the file expects to be
+       able to do so
+     Access will be denied with this patch. This only applies if the file is re-created.
+     In-place configuration files are unlikely to be affected.
+ 
+  * If
+     * a file was originally created with a less restrictive mode than the umask
+     * g_file_set_contents{,_full} is used to re-write the file
+     * A user with less permissions than needed to r/w/x the file attempts to do so
+    Access will be granted with this patch. This may present a security concern.
+    This is most likely to be relevant in hardened environments as umask 077 is
+    more common there.
+    It may be reasonable to assume that security-critical use cases would not rely
+    on g_file_set_contents for strict access controls as the documentation is
+    vauge: "[permissions] may be changed to mode depending on flags, or they may
+    remain unchanged".

  [ Original Description ]

  Is it possible to include this [1] upstream fix in Jammy and Noble?

  Steps to reproduce:
  ```
  root at test-jammy-01:/etc/dconf/db# dconf update
  root at test-jammy-01:/etc/dconf/db# ls -l local
- -rw-r--r-- 1 root root 61 Jul  9 12:27 local
+ -rw-r--r-- 1 root root 61 Jul 9 12:27 local
  root at test-jammy-01:/etc/dconf/db# umask
  0022
  root at test-jammy-01:/etc/dconf/db# umask 0077
  root at test-jammy-01:/etc/dconf/db# umask
  0077
  root at test-jammy-01:/etc/dconf/db# dconf update
  root at test-jammy-01:/etc/dconf/db# ls -l local
- -rw------- 1 root root 61 Jul  9 12:28 local
+ -rw------- 1 root root 61 Jul 9 12:28 local
  root at test-jammy-01:/etc/dconf/db# apt-cache policy dconf-cli
  dconf-cli:
-   Installed: 0.40.0-3
-   Candidate: 0.40.0-3
-   Version table:
-  *** 0.40.0-3 500
-         500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
-         100 /var/lib/dpkg/status
+   Installed: 0.40.0-3
+   Candidate: 0.40.0-3
+   Version table:
+  *** 0.40.0-3 500
+         500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
+         100 /var/lib/dpkg/status
  ```

  Danger of unexpected misconfiguration is great: others require read
  access to dconf-databases or their dconf-settings will not update as
  expected.

  [1] - https://gitlab.gnome.org/GNOME/dconf/-/issues/25

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2072586

Title:
  Running "dconf update" with different umask affects the permissions of
  dconf databases in /etc/dconf/db/

Status in glib2.0 package in Ubuntu:
  Fix Committed
Status in glib2.0 source package in Jammy:
  In Progress
Status in glib2.0 source package in Noble:
  In Progress
Status in glib2.0 source package in Oracular:
  In Progress
Status in glib2.0 source package in Plucky:
  In Progress

Bug description:
  [ Impact ]

  This was originally reported by a user applying the DISA-STIG on Ubuntu
  desktop [1], which requires a global umask of 077. The global dconf databases
  in /etc/dconf/db are intended to be read by many users (mode 644).

  dconf uses g_file_set_contents from GLib to guarantee consistent writes [2][3].
  The function creates a tempfile to rename over the original but does not
  guarantee that the permissions of the tempfile to be the same as the original [4].
  With umask 077, this causes a dconf database write to change the permissions of
  the db file from 644 to 600.

  This behavior was changed upstream in 45a36e52 to guarantee that the mode of the
  original file is preserved [5].

  The SRU of upstream 45a36e52 to Jammy+ will enable users to modify global GNOME
  configuration without losing read access to the changed dconf databases.

  [1] https://ubuntu.com/security/certifications/docs/disa-stig
  [2] https://git.launchpad.net/ubuntu/+source/dconf/tree/gvdb/gvdb-builder.c?h=ubuntu/jammy#n518
  [3] https://docs.gtk.org/glib/func.file_set_contents.html
  [4] https://docs.gtk.org/glib/func.file_set_contents_full.html#description
  [5] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4607

  [ Test Plan ]

  Ensure that the patch resolves the original bug:
  ```
  sudo apt-get install dconf-cli
  mkdir -p /etc/dconf/db/database.d
  cat >/etc/dconf/db/database.d/test <<EOF
  [test]
  hello='world'
  EOF
  dconf update
  ls -la /etc/dconf/db/database
  umask 0077
  dconf update
  ls -la /etc/dconf/db/database
  ```

  Expected result:
  -rw-r--r-- 1 root root 152 Apr 24 14:16 /etc/dconf/db/database

  Observed result:
  -rw------- 1 root root 152 Apr 24 14:16 /etc/dconf/db/database

  [ Where problems could occur ]

  GLib is depended upon by thousands of packages in Ubuntu (rdepends counts 3557
  in Jammy). It's unknown how many of these packages call g_file_set_contents{,_full}.

   * If
      * a file was originally created with a more restrictive mode than the umask
      * g_file_set_contents{,_full} is used to re-write the file
      * a user with less permissions than needed to r/w/x the file expects to be
        able to do so
      Access will be denied with this patch. This only applies if the file is re-created.
      In-place configuration files are unlikely to be affected.

   * If
      * a file was originally created with a less restrictive mode than the umask
      * g_file_set_contents{,_full} is used to re-write the file
      * A user with less permissions than needed to r/w/x the file attempts to do so
     Access will be granted with this patch. This may present a security concern.
     This is most likely to be relevant in hardened environments as umask 077 is
     more common there.
     It may be reasonable to assume that security-critical use cases would not rely
     on g_file_set_contents for strict access controls as the documentation is
     vauge: "[permissions] may be changed to mode depending on flags, or they may
     remain unchanged".

  [ Original Description ]

  Is it possible to include this [1] upstream fix in Jammy and Noble?

  Steps to reproduce:
  ```
  root at test-jammy-01:/etc/dconf/db# dconf update
  root at test-jammy-01:/etc/dconf/db# ls -l local
  -rw-r--r-- 1 root root 61 Jul 9 12:27 local
  root at test-jammy-01:/etc/dconf/db# umask
  0022
  root at test-jammy-01:/etc/dconf/db# umask 0077
  root at test-jammy-01:/etc/dconf/db# umask
  0077
  root at test-jammy-01:/etc/dconf/db# dconf update
  root at test-jammy-01:/etc/dconf/db# ls -l local
  -rw------- 1 root root 61 Jul 9 12:28 local
  root at test-jammy-01:/etc/dconf/db# apt-cache policy dconf-cli
  dconf-cli:
    Installed: 0.40.0-3
    Candidate: 0.40.0-3
    Version table:
   *** 0.40.0-3 500
          500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
          100 /var/lib/dpkg/status
  ```

  Danger of unexpected misconfiguration is great: others require read
  access to dconf-databases or their dconf-settings will not update as
  expected.

  [1] - https://gitlab.gnome.org/GNOME/dconf/-/issues/25

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2072586/+subscriptions