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