Re: Lockfile restart failure is still there :-( - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lockfile restart failure is still there :-(
Date
Msg-id 28306.1111101059@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lockfile restart failure is still there :-(  (Greg Stark <gsstark@mit.edu>)
Responses Re: Lockfile restart failure is still there :-(  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I am strongly tempted to add a direct check in checkDataDir() that the
>> data directory actually does belong to our own uid, just for paranoia's
>> sake.  Someone might decide that they could relax the permission check
>> ("hey, why not let the dbadmin group have write permission on $PGDATA")
>> without realizing they'd be weakening the startup safety interlock.

> Personally I often find I want to do exactly the kind of thing you're
> describing. Why does the whole directory have to be so restrictive? Why not
> just verify that the lock file itself is owned by our userid?

We need to be able to write in the whole directory, not just the
lockfile.  But actually the point I am making above is in your favor:
after adding a check on ownership, it would be a matter of your
protection wishes what the directory protections need to be.  Right
now that check is an integral part of some non-obvious safety
considerations.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Juan Pablo Espino
Date:
Subject:
Next
From: Juan Pablo Espino
Date:
Subject: Re: