Skip site navigation (1) Skip section navigation (2)

Re: Patch for - Allow server logs to be remotely read

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Dhanaraj(dot)M(at)Sun(dot)COM, pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for - Allow server logs to be remotely read
Date: 2006-06-08 14:36:38
Message-ID: 27342.1149777398@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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?

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-06-08 14:51:14
Subject: Re: Patch for - Allow server logs to be remotely read
Previous:From: Bruce MomjianDate: 2006-06-08 14:28:02
Subject: Re: Patch for - Allow server logs to be remotely read

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group