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 22:54:52
Message-ID: CA+TgmoYBndvdqgk4vuym6mMyz1SfV6X5h2d4b3LGwQ-83TX+bQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> 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.
>
> I agree that this makes it feel awkward. Peter had an interesting
> suggestion to make the dir aliases available as actual aliases for the
> commands which they would be relevant to. I hadn't considered that- I
> proposed 'diralias' because I didn't like 'directory' since we weren't
> actually creating *directories* but rather defining aliases to existing
> OS directories in PG.

Right. Another way to go at this would be to just ditch the names.
This exact syntax probably wouldn't work (or might not be a good idea)
because GRANT is so badly overloaded already, but conceptually:

GRANT READ ON DIRECTORY '/home/snowman' TO sfrost;

Or maybe some variant of:

ALTER USER sfrost GRANT READ ON DIRECTORY '/home/snowman';

> I'm not quite sure what to do with this comment. Perhaps it isn't at
> the top of anyone's list (not even mine), but I didn't think we rejected
> features because the community feels that some other feature is more
> important. If we're going to start doing that then we should probably
> come up with a list of what features the community wants, prioritize
> them, and require that all committers work towards those features to the
> exclusion of their own interests, or those of their employers or the
> companies they own/run. I hope I've simply misunderstood the
> implication here instead.

No, that's not what I'm saying. Come on. From my point of view what
happened is that a patch implementing a rather specific design for a
problem I personally viewed as somewhat obscure just sort of dropped
out of nowhere; and it came from people working at a company that is
also working on a bunch of other security-related features. I
wondered whether there was more to the story, but I guess not.

--
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 Jim Nasby 2014-10-28 22:59:04 Re: REINDEX CONCURRENTLY 2.0
Previous Message Demai Ni 2014-10-28 22:07:26 Re: foreign data wrapper option manipulation during Create foreign table time?