** Merge proposal linked: https://code.launchpad.net/~whershberger/ubuntu/+source/dconf/+git/dconf/+merge/485956
** Merge proposal linked: https://code.launchpad.net/~whershberger/ubuntu/+source/dconf/+git/dconf/+merge/485957 ** Merge proposal linked: https://code.launchpad.net/~whershberger/ubuntu/+source/dconf/+git/dconf/+merge/485959 ** Merge proposal linked: https://code.launchpad.net/~whershberger/ubuntu/+source/dconf/+git/dconf/+merge/485958 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 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 to 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
