Re: create tablespace fails silently, or succeeds improperly

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> I suspect this behavior is partially intentional, because tablespace
> >> creation now involves an extra level of subdirectory.  However, it's
> >> not clear to me why CREATE TABLESPACE is still changing the permissions
> >> on the parent directory.  Bruce, exactly what is the rationale here?
> 
> > Tom, is there a particular permission change you were wondering about?
> 
> In testing it, I noticed that the permissions of the parent directory
> (the one named in LOCATION) were changed to 0700, which is not where
> I'd had them set before.  I'm not sure that that is still necessary
> or reasonable.  We should make the subdirectory (eg PG_9.1_201010151)
> mode 0700, but I am dubious that it's still sensible to require
> ownership on the parent, much less to change its permissions.  The
> argument for locking down the parent seems to be to prevent a bad guy
> from renaming the subdirectory out of the way and substituting his own
> --- but if we're trying to prevent that type of attack, then we have to
> insist on restrictive permissions all the way up the path, not just on
> the immediate parent.  And we do not try to prevent such attacks on the
> $PGDATA directory itself, so why should we do it on a tablespace?
> 
> So basically I think this requires some re-thinking that it didn't get.
> Perhaps we should just be satisfied if we are able to create the
> subdirectory as owned by postgres, and leave it to the user as to
> whether the parent directory is a secure place to put the subdirectory.

Good point.  I did not think through the security restrictions of the
parent, but because we were symlinking to it, I thought we should lock
it down.  I see no problem in relaxing the restrictions as you suggest.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +