Re: Ignore lost+found when checking if a directory is empty - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ignore lost+found when checking if a directory is empty
Date
Msg-id 13340.1312925892@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ignore lost+found when checking if a directory is empty  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Ignore lost+found when checking if a directory is empty
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011:
>> I think I agree with Peter here that it's not a very good idea, and I
>> don't see a big upside. With tablespaces it seems to make a little bit
>> more sense, but I'd still lean away from that idea.

> What if the init script tries to start postmaster before the filesystems
> are mounted?  ISTM requiring a subdir is a good sanity check that the
> system is ready to run.  Not creating stuff directly on the mountpoint
> ensures consistency.

I went looking in the archives for previous discussions of this idea.
Most of them seem to focus on tablespaces rather than the primary data
directory, but the objections to doing it are pretty much the same
either way.  The security concerns I mentioned seem to boil down to this
(from <25791.1132238048@sss.pgh.pa.us>):
   Yeah, you *can* make it not-root-owned on most Unixen.  That doesn't   mean it's a good idea to do so.  For
instance,if the root directory   is owned by Joe Luser, what's to stop him from blowing away lost+found   and thereby
screwingup future fscks?  You should basically never have   more-privileged objects (such as lost+found) inside
directoriesowned by   less-privileged users --- it's just asking for trouble.
 
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: augmenting MultiXacts to improve foreign keys
Next
From: Tom Lane
Date:
Subject: Re: Reduced power consumption in autovacuum launcher process