Skip site navigation (1) Skip section navigation (2)

Re: create tablespace fails silently, or succeeds improperly

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: create tablespace fails silently, or succeeds improperly
Date: 2010-10-18 19:03:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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>

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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-10-18 19:04:14
Subject: Re: create tablespace fails silently, or succeeds improperly
Previous:From: Robert HaasDate: 2010-10-18 19:03:08
Subject: Re: create tablespace fails silently, or succeeds improperly

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group