Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.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/pltcl.so"
> 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
