Kevin,
* Kevin Grittner (kgrittn@ymail.com) wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > So at this point we've decided that we must forbid access to symlinked or
> > hardlinked files, which is a significant usability penalty; we've also
> > chosen to blow off most older platforms entirely; and we've only spent
> > about five minutes actually looking for security issues, with no good
> > reason to assume there are no more.
>
> What's interesting and disappointing here is that not one of these
> suggested vulnerabilities seems like a possibility on a database
> server managed in what I would consider a sane and secure manner[1].
For my part- I agree completely with this sentiment, and I'm not sure
that Tom disagrees with it. I believe the discussion is heading towards
a blanket "use this at your own risk- if the user can modify files in
these directories outside of PG, they can probably break your system"
being added in very bold lettering in the documentation around this.
It botheres me that we'd have to have a statement like that, but if we
have to then we have to.
> This feature is valuable because it is an alternative to allowing a
> user you don't trust *either* an OS login to the database server
> *or* a superuser database login. Can anyone suggest an exploit
> which would be available if we allowed someone who has permission
> to view all data in the database read permission to the pg_log
> directory and the files contained therein, assuming they do *not*
> have an OS login to the database server?
These are the use-cases which I've been wanting this for. Also, things
like ETL processes which run as a dedicated user and really have no
business nor need to be running as a superuser.
Thanks,
Stephen