Re: gconftool-2 using user's umask - bug in gconf?
- From: Mark McLoughlin <markmc redhat com>
- To: Havoc Pennington <hp redhat com>
- Cc: gconf-list gnome org
- Subject: Re: gconftool-2 using user's umask - bug in gconf?
- Date: Tue, 10 Aug 2004 16:39:41 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]