* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> So heaven help you if you grant user joe access in directory
> /home/joe/copydata, or any other directory whose parent is writable by
> him. He can just remove the directory and replace it with a symlink to
> whatever directory contains files he'd like the server to read/write for
> him.
Yeah, there's no workaround for this that I'm aware of- we'd have to
prevent subdirectories being provided by the user, I believe.
Reviewing procmail, maildrop, and other processes which do this sort of
operation, it looks like the common thread today is to setuid() instead,
but that only works if you're running as root, which we obviously don't
want to be doing either.
Kevin had a good question, I thought- are there issues if the DB user
doesn't have any access to the OS filesystem? Would it be sufficient to
say "Note that processes which can create objects in the directory
specified outside of PostgreSQL could create symlinks, hard links, or
other objects which might cause the PostgreSQL server to read files or
write files which it has access to that are outside of the directory
specified." ?
I still don't particularly like it and, frankly, the limitations we've
come up with thus far are not issues for my use-cases and I'd rather
have them and be able to say "yes, you can use this with some confidence
that it won't trivially bypass the DB security or provide a way to crash
the DB".
> Again, we could no doubt install defenses against that sort of case,
> once we realize it's a threat. Maybe they'd even be bulletproof defenses
> (not too sure how you'd prevent race conditions though). But whether they
> are or not, we just took the usability of the feature down another notch,
> because certainly that sort of directory arrangement would have been
> convenient for joe ... as long as he was trustworthy.
This "ad-hoc data load for Joe" use-case isn't where I had been going
with this feature, and I do trust the ETL processes that are behind the
use-case that I've proposed for the most part, but there's also no
reason for those files to be symlinks or have hard-links or have
subdirectories beyond those that I've specifically set up, and having
those protections seems, to me at least, like they'd be a good idea to
have, just in case.
If we punt on it entirely and refuse to check that the path provided by
the user hasn't got ".." in it, or that the file is an actual file and
not a symlink, etc, then we might as well make a "FILEACCESS" role
attribute and declare that you can trivially get superuser with it, if
you care to. The problem with that, as I see it, is that it'd close off
a different set of use-cases as I'm really on the fence about if I'd
want to give an ETL process that kind of access, just out of sheer
paranoia.
Thanks!
Stephen
