Re: PATCH: Configurable file mode mask

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Configurable file mode mask
Date: 2018-04-05 16:08:15
Message-ID: 49d7d548-0e56-fc6f-c946-d9ecd1c9eaf4@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi Michael,

On 4/5/18 2:55 AM, Michael Paquier wrote:
> On Wed, Apr 04, 2018 at 08:03:54PM -0400, David Steele wrote:
>
>> Instead I have created variables in file_perm.c
>> that hold the current file create mode, dir create mode, and mode mask.
>> All call sites use those variables (e.g. pg_dir_create_mode), which I
>> think are much clear.
>
> Hm. I personally find that even more confusing, especially with
> SetDataDirectoryCreatePerm which basically is the same as
> SetConfigOption for the backend.

The GUC shows the current mode of the data directory, while the
variables in file_perm.c store the mode that should be used to create
new dirs/files. One is certainly based on the other but I thought it
best to split them for clarity.

> In your case pg_dir_create_mode is not
> aimed at remaining a constant as you may change it depending on if
> grouping is enabled or not... And all the other iterations of such
> variables in src/common/ are constants (see NumScanKeywords or
> forkNames[] for example), so I cannot see with a good eye this change.

The idea is to have a variable that give the fir dir/file create mode
without having to trust that umask() is set correctly or do mode masking
on chmod(). This makes a number of call sites simpler and, I hope,
easier to read.

> You also forgot a call to SetDataDirectoryCreatePerm or
> pg_dir_create_mode remains to its default.

Are saying *if* a call is forgotten?

Yes, the file/dir create modes will use the default restrictive
permissions unless set otherwise. I see this as a good thing. Worst
case, we miss some areas where group access should be enabled and we
find those over the next few months.

What we don't want is a regression in the current, default behavior.
This is design is intended to avoid that outcome.

> The interface of file_perm.h that you are introducing is not confusing
> anymore though..

Yes, that was the idea. I think it makes it clearer what we are trying
to do and centralizes variables related to create modes in one place.

I've attached new patches that exclude Windows from permissions tests
and deal with bootstrap permissions in a better way. PostgresMain() and
AuxiliaryProcessMain() now use checkDataDir() to set permissions.

Thanks!
--
-David
david(at)pgmasters(dot)net

Attachment Content-Type Size
group-access-v15-01-file-perm.patch text/plain 42.1 KB
group-access-v15-02-group.patch text/plain 45.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2018-04-05 16:56:07 Re: new function for tsquery creartion
Previous Message Alvaro Herrera 2018-04-05 16:07:11 Re: [HACKERS] MERGE SQL Statement for PG11