Re: Directory/File Access Permissions for COPY and Generic File Access Functions

On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost <sfrost@snowman.net> wrote:
> There are more capabilities that I've been considering longer-term but
> wasn't sure if they should be independent or just lumped into the
> simpler read/write category:
>
> read (eg: importing log files, or importing from an NFS mount)
> write (eg: exporting to NFS mount)
> tablespace (eg: create a tablespace in a subdir of a directory)
> create directory (eg: create subdirs)
> modify permissions (eg: allow users other than pg to read/write/etc)
> directory listing
> large-object import/export (might be same as read/write)
> COPY PIPE

I think it would be a good idea to figure out how this fits together
and propose a design that covers all the cases you think are
important, and then see how many of them the community agrees are
important.  I have no problem with incremental commits moving toward
an agreed-upon design, but it's important that we don't go off in one
directly and then have to reverse course, because it creates upgrade
problems for our users.

To articular my own concerns perhaps a bit better, there are two major
things I don't like about the whole DIRALIAS proposal.  Number one,
you're creating this SQL object whose name is not actually used for
anything other than manipulating the alias you created.  The users are
still operating on pathnames.  That's awfully strange.  Number two,
every other SQL object we have has a name that is one or several
English words.  DIRALIAS does not appear in any dictionary.  The
second objection can be answered by renaming the facility, but the
first one is not so straightforward.

> I'll discuss with Adam putting a wiki together which outlines the use
> cases and rationale for them and hopefully that'll lead into a better
> discussion about the possible permissions which would make sense to
> exist for these and that may inform us as to if a GUC-based approach
> would work.  I'm still unsure about using GUCs to define permissions in
> this way.  That feels novel to me for PG to do, but I'll admit that I
> may just be ignorant or forgetting existing cases where we do that.

Well, there's temp_file_limit, for example.  That's not exactly the
same, but it bears a passing resemblance.

I'm definitely not saying that the GUC-based proposal is perfect.  It
isn't, and if we're going to need a whole bunch of different
permissions that are all per-directory, that could get ugly in a
hurry.  My points are (1) the community does not have to accept this
feature just because you propose it, and in fact there's a good
argument for rejecting it outright, which is that very few users are
going to get any benefit out of this, and it might end up being a
whole lot of code; and (2) the pros and cons of accepting this at all,
and of different designs, need to be debated here, on this list, in an
open way.

I think it would help, on all accounts, to explain why in the world
we're spending time on this in the first place.  I have a sneaking
suspicion this is 1 of N things we need to do to meet some US
government security standard, and if something like that is the case,
that could tip the balance toward doing it, or toward a particular
implementation of the concept.  From my point of view, if you made a
list of all of the annoyances of using PostgreSQL and listed them in
order of importance, you'd burn through a fair amount of paper before
reaching this one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company