Re: create tablespace fails silently, or succeeds improperly

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane