Fujii Masao <masao.fujii@gmail.com> writes:
> Probably true. But we cannot create a tablespace for root-owned directory.
> The directory must be owned by the PostgreSQL system user. So ISTM that
> you says that creating a tablespace on a mount point itself is a security hole.
Generally, the root user would have to mount the filesystem and then
create a Postgres-owned directory under it, yes. This is a feature not
a bug.
>> In the case you sketch, there would be nothing to stop the (non root)
>> postgres user from renaming $PGDATA/mnt to something else and then
>> inserting his own trojan-horse directories.
> Hmm.. can non-root postgres user really rename the root-owned directory
> while it's being mounted?
If you have write privilege on the parent directory, you can rename any
filesystem entry.
>> Moreover, I see no positive *good* reason to do it. �There isn't
>> anyplace under $PGDATA that users should be randomly creating
>> directories, much less mount points.
> When taking a base backup, you don't need to take a backup of tablespaces
> separately from that of $PGDATA. You have only to take a backup of $PGDATA.
Doesn't work, and doesn't tell you it didn't work, if the mount point
isn't mounted. I believe "what happens if the secondary filesystem
isn't mounted" is exactly one of the basic reasons for the
mount-points-must-be-owned-by-root rule. Otherwise, applications may
scribble directly on the / drive, which results in serious problems when
the mount eventually comes back. There's an example in our archives
(from Joe Conway if memory serves) about someone destroying their
database that way.
regards, tom lane
