Re: Re: PATCH: Configurable file mode mask

From: David Steele <david(at)pgmasters(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>
Subject: Re: Re: PATCH: Configurable file mode mask
Date: 2017-12-28 22:36:07
Message-ID: 48059786-a6fa-86ba-8d9b-c79201abd423@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/21/17 2:02 PM, David Steele wrote:
> On 3/18/17 3:57 PM, Robert Haas wrote:
>
>> I think Tom's concerns about people doing insecure stuff are
>> excessive.  People can do insecure stuff no matter what we do, and
>> trying to prevent them often leads to them doing even-more-insecure
>> stuff.  That having been aid, I do wonder whether the idea of allowing
>> group read privileges specifically might be a better concept than a
>> umask, though, because (1) it's not obvious that there's a real use
>> case for anything other than group read privileges, so why not support
>> exactly that to avoid user confusion and (2) umask is a pretty
>> specific concept that may not apply on every platform.  For example,
>> AFS has an ACL list instead of using the traditional UNIX permission
>> bits, and I'm not sure Windows has the umask concept exactly either.
>> So wording what we're trying to do a bit more generically might be
>> smart.
>
> We took Tom's advice to heart and this is the direction the patch is
> currently going in.  Even the GUC may be too much as there are number of
> tools that write into PGDATA but don't read postgresql.conf.  It looks
> like using the permissions of PGDATA may be the best way to go.
>
> In any case, the changes required have enlarged the size and scope of
> the patch considerably and we are not confident that it will be done in
> time to commit for v10.
>
> I have marked this submission "Returned with Feedback".

Attached is a new patch set that should address various concerns raised
in this thread.

1) group-access-v3-01-mkdir.patch

Abstracts all mkdir calls in the backend into a MakeDirectory() function
implemented in fd.c. This did not get committed in September as part of
0c5803b450e but I still think it has value. However, I have kept it
separate to reduce noise in the second patch. The mkdir() calls could
also be modified to use PG_DIR_MODE_DEFAULT with equivalent results.

2) group-access-v3-02-group.patch

This is a "GUC-less" implementation of group read access that depends on
the mode of the $PGDATA directory to determine which mode to use for
subsequent writes. The initdb option is preserved to allow group access
to be enabled when the cluster is initialized.

Only two modes are allowed (700, 750) and the error message on startup
is hard-coded to address translation concerns.

I'll add this to the 2018-01 CF.

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

Attachment Content-Type Size
group-access-v3-01-mkdir.patch text/plain 10.7 KB
group-access-v3-02-group.patch text/plain 13.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-28 22:43:58 Re: plpgsql function startup-time improvements
Previous Message Fabien COELHO 2017-12-28 22:03:23 Re: [HACKERS] pgbench more operators & functions