Re: Directory/File Access Permissions for COPY and Generic File Access Functions
От | Robert Haas |
---|---|
Тема | Re: Directory/File Access Permissions for COPY and Generic File Access Functions |
Дата | |
Msg-id | CA+TgmoYBndvdqgk4vuym6mMyz1SfV6X5h2d4b3LGwQ-83TX+bQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Directory/File Access Permissions for COPY and Generic File Access Functions (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Directory/File Access Permissions for COPY and Generic
File Access Functions
|
Список | pgsql-hackers |
On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost <sfrost@snowman.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
В списке pgsql-hackers по дате отправления: