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

On Fri, 2004-07-02 at 09:49, Mark McLoughlin wrote:

> > 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.

	What a wonderful pile of tripe ! :-)

	 Seems I never understood just how the "mode" argument to open(2)
really works:

       The  argument  mode specifies the permissions to use in case a
       new file is created. It is modified by the process’s umask in the
       usual way: the permissions  of  the  created file are 
       (mode & ~umask).

	So, setting the umask in gconftool is the right way to go, but I think
it makes sense to only do that with --makefile-install-rule.

Cheers,
Mark.