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

[Jaimes Joschko]

[ 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].

45a36e52 has been picked into debian/latest and is present in Questing (glib2.0=2.84.1-2).

g_file_set_contents is used in over 300 packages in Debian [6]. The potential
for a backport of 45a36e52 to break some use-case is rather high. Because this
is an easily worked-around issue that has only been relevant for users applying
DISA-STIG on Ubuntu, applying the upstream fix is not worth the regression risk.

That said, I'd still like to see this fixed in LTS as DISA-STIG users also often
have FIPS requirements, so won't be able to take advantage of the upstream fix
for several years.

The original upstream bug report included a patch for dconf that implements the
same semantics as 45a36e52 [7]. That patch was rejected upstream because it has
a race condition [8]. However, the race is extremely unlikely and any broken
behavior is trivial to correct with chmod (see "What problems could occur").

A modified version of that patch has been carried in OpenSUSE for 8 years with
no bugs I was able to find [9][10]. I'm submitting the original patch as its
behavior more closely resembles the glib change.

As the dconf version in Questing is the same as Plucky (0.40.0-5) and it does
not need changes (as the upstream fix is present in Questing), I suspect
that Questing needs a no-change bump (0.40.0-5ubuntu1) before Plucky
(0.40.0-5ubuntu0.1) is accepted.

[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
[6] https://codesearch.debian.net/search?q=g_file_set_contents
[7] https://bugzilla.gnome.org/show_bug.cgi?id=758066
[8] https://gitlab.gnome.org/GNOME/gvdb/-/merge_requests/27
[9] https://build.opensuse.org/package/show/openSUSE:Factory/dconf
[10] https://bugzilla.opensuse.org/buglist.cgi?quicksearch=dconf

[ 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

Regression check:
On Ubuntu Desktop, use gsettings to set a configuration key:
```
gsettings set org.gnome.mutter center-new-windows false
```
Ensure that the setting takes effect in mutter (open a new window), and check
the syslog for permissions errors.

[ Where problems could occur ]

The patch I'm proposing for SRU contains a race condition; the permissions of
a dconf database may be incorrect for a short time between the move-over and
chmod. There are two problem cases:

 * An application attempts to read the dconf database between the move of the
   tempfile & the chmod, resulting in a permissions error. A retry should
   work around this. Because dconf writes are extremely uncommon, the chances
   of this occuring are very low (it was not reported in OpenSUSE for 8 years).

 * dconf crashes or is killed between the move and the chmod, causing the file
   to retain incorrect permissions. This is the current behavior of dconf and
   can be resolved with a chmod of the file to the desired permissions.

[ Original Description ]

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

Steps to reproduce:
```
root@test-jammy-01:/etc/dconf/db# dconf update
root@test-jammy-01:/etc/dconf/db# ls -l local
-rw-r--r-- 1 root root 61 Jul 9 12:27 local
root@test-jammy-01:/etc/dconf/db# umask
0022
root@test-jammy-01:/etc/dconf/db# umask 0077
root@test-jammy-01:/etc/dconf/db# umask
0077
root@test-jammy-01:/etc/dconf/db# dconf update
root@test-jammy-01:/etc/dconf/db# ls -l local
-rw------- 1 root root 61 Jul 9 12:28 local
root@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

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steven LaCosse (motosteven)]

Confirmed this is the case which this should be classified as a security hole as the behavior does not read dconf db anymore for the users.

Security for dconf needs to be set but is unable to be read when dconf update issued with UMASK.

DISA STIG USG fix applies UMASK in this manner which is how I found this.

[Wesley Hershberger (whershberger)]

I've opened 3 merge proposals upstream to begin to address this.

[1] https://gitlab.gnome.org/GNOME/gvdb/-/merge_requests/27
[2] https://gitlab.gnome.org/GNOME/gvdb/-/merge_requests/28
[3] https://gitlab.gnome.org/GNOME/dconf/-/merge_requests/89

[Wesley Hershberger (whershberger)]

Per my upstream MR, this is a bug in GLib, not dconf [1]. I've opened & pushed through [2], which has been graciously picked to debian/latest (thanks Jeremy).

[1] https://gitlab.gnome.org/GNOME/gvdb/-/merge_requests/27
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4607
[3] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4608

[Daniel van Vugt (vanvugt)]

It looks like Ubuntu/Debian patches should be proposed to https://salsa.debian.org/gnome-team/glib instead of Launchpad.

[Wesley Hershberger (whershberger)]

Thanks for the note; I've opened MRs against that repo:

https://salsa.debian.org/gnome-team/glib/-/merge_requests/49
https://salsa.debian.org/gnome-team/glib/-/merge_requests/50
https://salsa.debian.org/gnome-team/glib/-/merge_requests/51
https://salsa.debian.org/gnome-team/glib/-/merge_requests/52

[Launchpad Janitor (janitor)]

This bug was fixed in the package glib2.0 - 2.84.1-2

---------------
glib2.0 (2.84.1-2) unstable; urgency=medium

  * Cherry-pick 2 commits from glib-2-84 branch (LP: #2072586)

 -- Jeremy Bícha <email address hidden> Thu, 24 Apr 2025 15:26:06 -0400

[Wesley Hershberger (whershberger)]

I had a few conversations with Heitor, Matthew & Jeremy last week regarding this SRU. Heitor and Matthew (SRU Sponsors for Sustaining Engineering) are both hesitant to sponsor this due to the potential blast radius of a change of semantics in g_file_set_contents (see debian codesearch at [1][2]; this could affect _many_ packages).

The alternative is to SRU dconf with the patch I submitted in gvdb (rejected upstream) [3]. That patch has been carried in OpenSUSE for 8 years [4]; a quick review of their bugtracker shows no permissions-related bugs in that package [5]. That patch was rejected because it allows the permissions to be incorrect for a short time until the chmod completes:
 * An application attempts to read the dconf database between the move of the tempfile & the chmod, resulting in a permissions error
 * dconf crashes or is killed between the move and the chmod, causing the file to retain incorrect permissions

Both of these scenarios are extremely unlikely as dconf changes are uncommon, and they are easy to recover from.

Because this bug only impacts DISA-STIG users, I think this is a more reasonable trade-off between risk to Ubuntu users in general and a viable fix for the bug.

I will prepare alternative MPs in Launchpad (looks like Ubuntu dconf is not maintained in salsa) with the patch & update the SRU template accordingly. Thanks for your patience.

[1] https://codesearch.debian.net/search?q=g_file_set_contents
[2] https://codesearch.debian.net/results/4858c71f9ca47f0e/packages.txt
[3] https://gitlab.gnome.org/GNOME/gvdb/-/merge_requests/27
[4] https://build.opensuse.org/package/show/openSUSE:Factory/dconf
[4] https://bugzilla.opensuse.org/buglist.cgi?quicksearch=dconf