Re: logfile subprocess and Fancy File Functions

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: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: logfile subprocess and Fancy File Functions
Date: 2004-07-24 16:32:36
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>> Thinking we have security because they can't guess
>>> pgdata seems like security through obscurity to me.
>> Sure, but it's still a useful roadblock to throw in an attacker's way.

> As a super-user, could an attacker load a server-side language and
> access the backend environment variable PGDATA.

Only if it's set. A security-conscious DBA might prefer to start the
postmaster with -D instead of setting an environment variable. (In fact
I wonder whether we shouldn't make the postmaster unsetenv PGDATA after
it's set the data directory. This would be good for debugging purposes,
ie catching any subprocesses that mistakenly assume PGDATA must be a
correct pointer to the datadir, as well as for security reasons.)

> Also look at this:

> test=> CREATE FUNCTION "xxx_call_handler" () RETURNS language_handler AS '$libdir/pltcl' LANGUAGE C;
> ERROR: could not find function "xxx_call_handler" in file "/usr/var/local/postgres/lib/"

> Notice the expansion of "$libdir".

Yah, but that only tells him where libdir is, which shouldn't help him
much. In any hardened installation, that directory tree won't be
writable by postgres at all.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-07-24 16:42:45 Re: logfile subprocess and Fancy File Functions
Previous Message Bruce Momjian 2004-07-24 16:12:52 Re: logfile subprocess and Fancy File Functions