debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #00525
[Bug 2072586] Re: Running "dconf update" with different umask affects the permissions of dconf databases in /etc/dconf/db/
** 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].
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 to permissions errors.
+ 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.
+ * 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
+ 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
Debcrafters packages, which is subscribed to dconf 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 dconf:
Fix Released
Status in dconf package in Ubuntu:
Invalid
Status in glib2.0 package in Ubuntu:
Fix Released
Status in dconf source package in Jammy:
In Progress
Status in glib2.0 source package in Jammy:
Won't Fix
Status in dconf source package in Noble:
In Progress
Status in glib2.0 source package in Noble:
Won't Fix
Status in dconf source package in Oracular:
In Progress
Status in glib2.0 source package in Oracular:
Won't Fix
Status in dconf source package in Plucky:
In Progress
Status in glib2.0 source package in Plucky:
Won't Fix
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/dconf/+bug/2072586/+subscriptions
