Re: PATCH: Configurable file mode mask - Mailing list pgsql-hackers

Greetings Chapman,

* Chapman Flack (chap@anastigmatix.net) wrote:
> On 03/13/2018 01:50 PM, Stephen Frost wrote:
> > PG will stat PGDATA and conclude that the system is saying that group
> > access has been granted on PGDATA and will do the same for subsequent
> > files created later on. ... The only issue that remains is that PG
> > doesn't understand or work with POSIX ACLs or Linux capabilities,
> > but that's not anything new.
>
> What's new is that it is now pretending even more extravagantly to
> understand what it doesn't understand. Where it would previously draw
> in incorrect conclusion and refuse to start, which is annoying but
> not very difficult to work around if need be, it would now draw the
> same incorrect conclusion and then actively go about making the real
> world embody the incorrect conclusion, contrary to the admin's efforts.

I have to say that I disagree about it being "easy to work-around" PG
refusing to start.  Also, we're not pretending any more or less, we're
sticking to exactly what we do understand- which is the 80's unix
permission system, as you put it.  The options that I see here are to
stick with the user/group system and our naive understanding of it, to
go whole-hog and try to completely understand everything (with lots of
#ifdef's, as discussed), or to completely remove all checks- but we
don't have a clear proposal for that and it strikes me as at least
unlikely to go over well anyway, given all of the discussion here about
trying to simply change the one check we have.

> >> umask inherited by the postmaster. A --permission-transparency option
> >> would simply use open and mkdir in the traditional ways, allowing
> >> the chosen umask, ACL defaults, SELinux contexts, etc., to do their
> >> thing, and would avoid then stepping on the results with explicit
> >> chmods (and of course skip the I-refuse-to-start-because-I-
> >> misunderstand-your-setup check).
> >> ...
> >
> > I'm a fan of this idea in general, but it's unclear how that
> > --permission-transparency option would work in practice.  Are you
> > suggesting that it be a compile-time flag, which would certainly work
> > but also then have to be debated among packagers as to the right setting
> > and if there's any need to be concerned about users misunderstanding it,
> > or a flag for each program,
>
> I was thinking of a command-line option ...
>
> > which hardly seems ideal as some invokations
> > of programs might forget to specify that, leading to inconsistent
> > permissions, or something else..?
>
> ... but I see how that gets complicated with the various other command-
> line utilities included.

Indeed.

> > .. we'd have to build in complete
> > support for POSIX ACLs and Linux capabilities if we go down a route
>
> I'm wary of an argument that we can't do better except by building
> in complete support for POSIX ACLs, and capabilities (and NFSv4
> ACLs, and SELinux, and AppArmor, and #ifdef and #ifdef and #ifdef).

I don't think I meant to imply that we can't do better, I was just
trying to enumate what I saw the different options being.

> It seems to me that, in most cases, the designers of these sorts of
> extensions to old traditional Unix behavior take great pains to design
> them such that they can still usefully function in the presence of
> programs that "don't pay attention to or understand or use" them, as
> long as those programs are in some sense well-behaved, and not going
> out of their way with active steps that insist on or impose permissions
> that aren't appropriate under the non-understood circumstances.
>
> So my suggestion boils down to PG having at least an option, somehow,
> to be well-behaved in that sense.

I'm afraid that we haven't got any great answer to that "somehow".  I
was hoping you might have some other ideas beyond command-line switches
which could leave the system in an inconsistent state a bit too easily.
Unless there's a better way then the approach proposed by Tom
(originally) and implemented by David seems like the way to go and at
least an improvement over the current situation.

Thanks!

Stephen