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

Bug #2072586 reported by Jaimes Joschko
286
This bug affects 5 people
Affects Status Importance Assigned to Milestone
dconf
Fix Released
Unknown
dconf (Ubuntu)
Invalid
Undecided
Unassigned
Jammy
In Progress
Medium
Wesley Hershberger
Noble
In Progress
Medium
Wesley Hershberger
Oracular
In Progress
Medium
Wesley Hershberger
Plucky
In Progress
Medium
Wesley Hershberger
glib2.0 (Ubuntu)
Fix Released
Undecided
Wesley Hershberger
Jammy
Won't Fix
Medium
Wesley Hershberger
Noble
Won't Fix
Medium
Wesley Hershberger
Oracular
Won't Fix
Medium
Wesley Hershberger
Plucky
Won't Fix
Medium
Wesley Hershberger

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

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

Related branches

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in dconf (Ubuntu):
status: New → Confirmed
Revision history for this message
Steven LaCosse (motosteven) wrote (last edit ):

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.

tags: added: sts
Changed in dconf (Ubuntu):
assignee: nobody → Wesley Hershberger (whershberger)
description: updated
Revision history for this message
Wesley Hershberger (whershberger) wrote :
Jeremy Bícha (jbicha)
affects: dconf (Ubuntu) → glib2.0 (Ubuntu)
Changed in glib2.0 (Ubuntu):
status: Confirmed → Triaged
Changed in glib2.0 (Ubuntu Jammy):
status: New → Triaged
Changed in glib2.0 (Ubuntu Noble):
status: New → Triaged
Changed in glib2.0 (Ubuntu Plucky):
status: New → Triaged
Changed in glib2.0 (Ubuntu Jammy):
assignee: nobody → Wesley Hershberger (whershberger)
Changed in glib2.0 (Ubuntu Plucky):
assignee: nobody → Wesley Hershberger (whershberger)
Changed in glib2.0 (Ubuntu Noble):
assignee: nobody → Wesley Hershberger (whershberger)
Jeremy Bícha (jbicha)
Changed in glib2.0 (Ubuntu):
status: Triaged → Fix Committed
description: updated
Revision history for this message
Wesley Hershberger (whershberger) wrote :

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

Changed in glib2.0 (Ubuntu Oracular):
status: New → Triaged
assignee: nobody → Wesley Hershberger (whershberger)
Changed in glib2.0 (Ubuntu Jammy):
status: Triaged → In Progress
Changed in glib2.0 (Ubuntu Noble):
status: Triaged → In Progress
Changed in glib2.0 (Ubuntu Oracular):
status: Triaged → In Progress
Changed in glib2.0 (Ubuntu Plucky):
status: Triaged → In Progress
description: updated
description: updated
description: updated
Jeremy Bícha (jbicha)
information type: Public → Public Security
affects: glib → dconf
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

tags: added: fixed-in-glib-2.85 fixed-upstream
Changed in glib2.0 (Ubuntu):
milestone: none → ubuntu-25.10
Changed in dconf:
status: Unknown → Fix Released
Revision history for this message
Wesley Hershberger (whershberger) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in glib2.0 (Ubuntu):
status: Fix Committed → Fix Released
Changed in glib2.0 (Ubuntu Plucky):
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu Oracular):
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu Noble):
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu Jammy):
importance: Undecided → Medium
Revision history for this message
Wesley Hershberger (whershberger) wrote :

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

description: updated
Changed in dconf (Ubuntu):
status: New → Invalid
Changed in dconf (Ubuntu Jammy):
status: New → In Progress
Changed in dconf (Ubuntu Noble):
importance: Undecided → Medium
status: New → In Progress
Changed in dconf (Ubuntu Jammy):
assignee: nobody → Wesley Hershberger (whershberger)
importance: Undecided → Medium
Changed in dconf (Ubuntu Noble):
assignee: nobody → Wesley Hershberger (whershberger)
Changed in dconf (Ubuntu Oracular):
assignee: nobody → Wesley Hershberger (whershberger)
importance: Undecided → Medium
status: New → In Progress
Changed in dconf (Ubuntu Plucky):
assignee: nobody → Wesley Hershberger (whershberger)
importance: Undecided → Medium
status: New → In Progress
Changed in glib2.0 (Ubuntu Jammy):
status: In Progress → Won't Fix
Changed in glib2.0 (Ubuntu Noble):
status: In Progress → Won't Fix
Changed in glib2.0 (Ubuntu Oracular):
status: In Progress → Won't Fix
Changed in glib2.0 (Ubuntu Plucky):
status: In Progress → Won't Fix
description: updated
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.