Re: gconftool-2 using user's umask - bug in gconf?

[Mark McLoughlin <markmc redhat com>]

Hey,

On Sat, 2004-06-26 at 15:35, Havoc Pennington wrote:
> On Sat, 2004-06-26 at 10:33, Havoc Pennington wrote:
> > On Sat, 2004-06-26 at 06:10, Rubens Ramos wrote:
> > >  So - is gconftool-2 supposed to create directories in 
> > > /etc/gconf/gconf.xml.defaults with the same umask as the user
> > > who's executing it?
> > 
> > It doesn't seem right to me, no. Should be a one-line fix right?
> > 
> 
> Here's the issue: gconfd calls umask(022), but gconftool doesn't go
> through the daemon. We need to add a umask(022) to gconftool also.
> I'd say it's wrong to add it to the backends/libraries since it's a
> global setting.

	Okay, here's how it currently works:

 * The root directory of a given source is always created 700 if it 
   doesn't exist

 * Any other files and directories created by the backend in a source 
   depend on the permissions of the root directory of that source. So, 
   if the root has perms of 755, subdirs will be created with 755 and 
   new files will be created with 644.

 * The umask in gconfd is entirely ignored by the backend AFAICS.

	The reason for this is pretty clear I think - the umask is not a global
setting - its a per-source setting. You want the system wide database to
be world readable, but you certainly don't want the user's database to
be world readable.

	The way we ensure things work correctly is to make sure the GConf
package installs the gconf.xml.defaults and gconf.xml.mandatory
directories as 755. What we need to do is figure out where this is
breaking down.

Cheers,
Mark.