Re: create tablespace fails silently, or succeeds improperly

Tom Lane wrote:
> 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.

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +