debcrafters-packages team mailing list archive

[Wesley Hershberger <2072586@xxxxxxxxxxxxxxxxxx>]

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

-- 
You received this bug notification because you are a member of
Debcrafters 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 glib2.0 package in Ubuntu:
  Fix Released
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].

  45a36e52 has been picked into debian/latest.

  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
      * the file is re-recreated with the more restrictive mode
      * 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.
      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@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