Stephen Frost <sfrost@snowman.net> writes:
> Agreed- additional input from others would be great.
I think this entire concept is a bad idea that will be a never-ending
source of security holes. There are too many things that a user with
filesystem access can do to get superuser-equivalent status.
Here is one trivial example: you want to let user joe import COPY
data quickly, so you give him read access in directory foo, which he
has write access on from his own account. Surely that's right in the
middle of use cases you had in mind, or even if it wasn't, it sounds
like a good idea no? The problem is he can create symlinks, not just
files, in that directory, and by pointing the symlink to the right
place he can read any file the server can read. pg_hba.conf, pg_authid,
or even just tables he shouldn't have access to. With a little luck he
can crack the superuser's password, but even without that you've given
him access to sensitive information.
If you were dumb enough to give joe *write* access in such a directory,
so that he could COPY in both directions, it's game over altogether: he
can become superuser in any number of ways, most easily by hacking
pg_hba.conf.
You could ameliorate this problem by checking to see that the read/write
target is a file not a symlink, but that's still subject to filesystem
race conditions that could be exploited by anyone with the ability to
retry it enough times.
The larger point though is that this is just one of innumerable attack
routes for anyone with the ability to make the server do filesystem reads
or writes of his choosing. If you think that's something you can safely
give to people you don't trust enough to make them superusers, you are
wrong, and I don't particularly want to spend the next ten years trying
to wrap band-aids around your misjudgment.
Therefore, I'm going to be against committing any feature of this sort.
If the objective is to give filesystem capabilities to someone you *do*
trust, but they'd prefer to use it from an account without full superuser
privileges, that can be solved much more simply by making access to the
existing superuser-only I/O functions more granular. That fits in just
fine with the other project you've got of breaking down superuserness into
smaller privileges. But if we build a feature designed in the way being
discussed in this thread, people will think it can be used to grant
limited filesystem access to users they don't completely trust, and we're
going to have to deal with the fallout from that.
regards, tom lane
