Tom Lane wrote: > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
