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

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > That said, it sounds like the primary concern has been if we want this
> > feature at all and there hasn't been much discussion of the design
> > itself. Comments about the technical design would be great. I
> > appreciate your thoughts about using a PGC_SUSER GUC, but I don't feel
> > like it really works as it's all-or-nothing and doesn't provide
> > read-vs-write, unless we extend it out to be multiple GUCs and then
> > there is still the question about per-role access..
>
> It sounds to me like you've basically settled on the way that you want
> to implement it - without prior discussion on the mailing list - and
> you're not trying very hard to make any of the alternatives work.

I'm happy to put more effort into alternatives, was just trying to
outline what capabilities I felt it should have and make sure others
proposing designs understood the granularity requested.

> It's not the community's job to come up with a design that satisfies
> you; it's your job to come up with as design that satisfies the
> community. That doesn't *necessarily* mean that you have to change
> the design that you've come up with; convincing other people that your
> design is the best one is also an option. But I don't see that you're
> making any real attempt to do that.

There was only one other design to contrast against- the rest has been
concern about the desirability, which is what I've been trying to
address by responding to Peter's request about documentation and how
this capability exists in other systems.

> Your previous comment on the idea of a PGC_SUSET GUC was "Hrm, perhaps
> this would work though.." and then, with zero further on-list
> discussion, you've arrived at "I don't feel like it really works as
> it's all-or-nothing and doesn't provide read-vs-write". Those are
> precisely the kinds of issues that you should be discussing here in
> detail, not cogitating on in isolation and then expecting this group
> of people to accept that your original design is really for the best
> after all.

Alright, I'll try and outline a more detailed proposal which uses GUCs
to achieve the level of granularity that is being sought and we can
discuss it.

> I also find your technical arguments - to the extent that you've
> bothered to articulate them at all - to be without merit. The
> "question about per-role access" is easily dealt with, so let's start
> there: if you make it a GUC, ALTER USER .. SET can be used to set
> different values for different users. No problem.

No, I simply hadn't thought about that approach and I'm glad that you're
clarifying it.. I'll think about it more but my initial concern is
being able to identify everything a user has access to would then become
more complex as you'd have to consider what special GUCs they have set
in pg_config. I see how what you're proposing would work there though.

> Your other
> criticism that it is "all-vs-nothing" seems to me to be totally
> incomprehensible, since as far as I can see a GUC with a list of
> pathnames is exactly the same functionality that you're proposing to
> implement via a much more baroque syntax. It is no more or less
> all-or-nothing than that.

Apologies about not being clear- that 'all-or-nothing' was without
considering using a per-user GUC to control it; I had thought the
proposal was a single GUC and then a role attribute which said if a
given role could access everything in the global list or not. Using a
per-role GUC solves that.

> Finally, you mention "read-vs-write"
> access. You haven't even attempted to argue that we need to make that
> distinction

The use-case that I had described up-thread, I had thought, made it
clear that there will be cases where a user should have only read-only
access to a directory (able to import log files) and cases where a user
should be able to write to a directory (exporting to an NFS mount or
similar).

> - in fact, you don't seem to have convinced a
> significantly majority of the people that we need this feature at all

That's certainly what I've been primairly focused on addressing as it's
the first hurdle to jump. As I mentioned to Bruce, I didn't realize
there was really a question about that, but evidently that was
incorrect and I'm working to rectify the situation.

> - but if we do, the fact that it might require two GUCs instead of one
> is not a fatal objection to that design. (I'd be prepared to concede
> that if there are half a dozen different privileges on directories
> that we might want to grant, then wedging it into a GUC might be a
> stretch.)

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 can see cases where you wouldn't want to allow a directory listing,
but would want to allow read (or write), for example. There are also
cases where you would or wouldn't want a given user to be able to chmod
the files. I'm not sure that it should matter if it's a large object or
not, or if it's being used by file_fdw vs. normal COPY, but they're
certainly things to consider. The tablespace case is one which I think
really needs a lot of consideration since it could be particularly
dangerous, as well as COPY PIPE (which might not ever be able to be for
non-superuser, in the end..).

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.

Thanks for explaining the GUC-based proposal further.

Stephen