After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564056 - Protect against umask(0177)
Protect against umask(0177)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.32
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-11 00:03 UTC by Behdad Esfahbod
Modified: 2010-12-22 23:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Behdad Esfahbod 2008-12-11 00:03:39 UTC
I found this bug because I mistakenly added a "umask(0177)" to
gnome-settings-daemon.  This causes both fontconfig and gstreamer to create
their cache directory with that umask, effectively making it unusable.  This
was causing gstreamer to fail to update cache in its forked child, then trying
again from parent, failing there too and deciding to die, crashing my
gnome-settings-daemon process!  I predicted that out in my previous mail...

Anyway, other than not retrying from the parent, gstreamer should:

  1) chmod() its directory after creating,
  2) If writing to directory fails, try again after a chmod.

That's also what I'm going to make fontconfig do.

More details (much more than you'd ever want to read) at:
http://mces.blogspot.com/2008/12/improving-login-time-part-3.html
Comment 1 David Schleef 2008-12-11 00:12:27 UTC
I have half a mind to add:

  old_umask = umask(0);
  if (old_umask & 0700) {
    g_warning("Fix your broken umask");
    umask (old_umask & ~0700);
  } else {
    umask (old_umask);
  }

Have I mentioned that I despise umask()?
Comment 2 Behdad Esfahbod 2008-12-11 00:13:56 UTC
I like the g_warning, but changing umask is racy and should be avoided from library code.
Comment 3 David Schleef 2008-12-11 00:40:49 UTC
It was mostly a joke.

It appears the best way to guess the current umask is to create a file or directory and look at the permissions.  Which returns us to what you say above.

Comment 4 Behdad Esfahbod 2008-12-11 00:43:39 UTC
So yeah, skip the look and go directly to chmod.
Comment 5 David Schleef 2010-12-05 05:09:50 UTC
commit 5cdcdaee07c1f81a0abdd3885050118474e6c079
Author: David Schleef <ds@schleef.org>
Date:   Sat Dec 4 21:06:34 2010 -0800

    registry: Fix permissions if umask is broken
    
    Fixes: #564056.