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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Date: 2014-10-28 14:46:44
Message-ID: CA+Tgmobn7hyUKxgGjBVMZthYG2MdvWhMBaK9Zs0Z9c=SDMPW3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
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.

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.

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. 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. Finally, you mention "read-vs-write"
access. You haven't even attempted to argue that we need to make that
distinction - in fact, you don't seem to have convinced a
significantly majority of the people that we need this feature at all
- 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.)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2014-10-28 14:47:35 Re: [WIP Patch] Using 128-bit integers for sum, avg and statistics aggregates
Previous Message Heikki Linnakangas 2014-10-28 14:40:06 Re: [WIP Patch] Using 128-bit integers for sum, avg and statistics aggregates