Re: OpenFile() Permissions Refactor

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: David Steele <david(at)pgmasters(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OpenFile() Permissions Refactor
Date: 2017-09-01 17:15:24
Message-ID: 02607f60-61bd-d5e9-5c74-d46261f4b37b@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/29/17 12:15, David Steele wrote:
> While working on the patch to allow group reads of $PGDATA I refactored
> the various OpenFile() functions to use default/global permissions
> rather than permissions defined in each call.
>
> I think the patch stands on its own regardless of whether we accept the
> patch to allow group permissions (which won't make this CF). We had a
> couple different ways of defining permissions (e.g. 0600 vs S_IRUSR |
> S_IWUSR) and in any case it represented quite a bit of duplication.
> This way seems simpler and less error-prone.

Yeah, it would be good to clean some of that up.

I wonder whether we even need that much flexibility. We already set a
global umask, so we could just open all files with 0666 and let the
umask sort it out. Then we don't need all the *Perm() variants.

I don't like the function-like macros in fd.h. We can use proper functions.

I also wonder whether the umask save-and-restore code in copy.c and
be-fsstubs.c is sound. If the AllocateFile() call in between errors
out, then there is nothing that restores the original umask. This might
need a TRY/CATCH block, or maybe just a chmod() afterwards.

The mkdir() calls could perhaps use some further refactoring so you
don't have to specify the mode everywhere.

This kind of code:

- if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
+ if (stat_buf.st_mode & PG_MODE_MASK_DEFAULT)
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("data directory \"%s\" has group or world access",
DataDir),
- errdetail("Permissions should be u=rwx (0700).")));
+ errdetail("Permissions should be (%04o).",
PG_DIR_MODE_DEFAULT)));

can be problematic, because we are hoping that PG_MODE_MASK_DEFAULT,
PG_DIR_MODE_DEFAULT, and the wording in the error message can stay
consistent.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2017-09-01 17:22:22 Re: GnuTLS support
Previous Message Robert Haas 2017-09-01 17:13:22 Re: Parallel Hash take II