Re: Directory/File Access Permissions for COPY and Generic File Access Functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Date
Msg-id 31205.1414612138@sss.pgh.pa.us
Whole thread Raw
In response to Re: Directory/File Access Permissions for COPY and Generic File Access Functions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Directory/File Access Permissions for COPY and Generic File Access Functions
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> This "ad-hoc data load for Joe" use-case isn't where I had been going
> with this feature, and I do trust the ETL processes that are behind the
> use-case that I've proposed for the most part, but there's also no
> reason for those files to be symlinks or have hard-links or have
> subdirectories beyond those that I've specifically set up, and having
> those protections seems, to me at least, like they'd be a good idea to
> have, just in case.

If your ETL process can be restricted that much, can't it use file_fdw or
some such to access a fixed filename set by somebody with more privilege?
Why exactly does it need freedom to specify a filename but not a directory
path?

As for the DBA-access set of use cases, ISTM that most real-world needs
for this sort of functionality are inherently a bit ad-hoc, and therefore
once you've locked it down tightly enough that it's credibly not
exploitable, it's not really going to be as useful as all that.  The
nature of an admin job is dealing with unforeseen cases.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Next
From: Stephen Frost
Date:
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions