Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I wonder if we should take pg_read_file (and the rest of genfile.c)
> >> back out of the backend and stick them into contrib/adminpack.
>
> > I thought about that but what we have in the backend now is read-only
> > which basically could be done using COPY, so I don't see any security
> > value to moving them out. They are super-user only just like COPY.
>
> The you-can-do-it-with-COPY argument doesn't apply to pg_ls_dir, nor to
> pg_stat_file, and I find it unconvincing even for pg_read_file. COPY
> isn't at all friendly for trying to read binary files, for instance.
> Even for plain ASCII text you'd have to try to find a delimiter
> character not present anywhere in the file, and backslashes in the file
> would get corrupted.
>
> But the basic point here is that someone who wants filesystem access
> from the database is going to install adminpack anyway. Why should
> someone who *doesn't* want filesystem access from the database be
> forced to have some capabilities of that type installed anyway?
Remember we went around and around on this with the pgAdmin guys, so you
are going to have to get their input. Also consider that pgAdmin might
be doing remote administration on a database it can't load shared
objects into, so having the read stuff always be there might help them.
I don't see anyone complaining about our read-only file access in the
backend, so I don't see a readon to remove it.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
