Robert Haas <robertmhaas@gmail.com> writes:
> I have to admit that I'm a little afraid that people will mistake this
> for an actual security feature and file bug reports or CVEs about the
> superuser being able to circumvent these restrictions. If we add this,
> we had better make sure that the documentation is extremely clear
> about what we are guaranteeing, or more to the point about what we are
> not guaranteeing.
> I understand that there's some frustration on the part of Gabriele and
> others that this proposal hasn't been enthusiastically adopted, but I
> would ask for a little bit of forbearance because those are also, by
> and large, not the people who will not have to cope with it when we
> start getting security researchers threatening to publish our evilness
> in the Register. Such conversations are no fun at all.
Indeed. I'd go so far as to say that we should reject not only this
proposal, but any future ones that intend to prevent superusers from
doing things that superusers normally could do (and, indeed, are
normally expected to do). That sort of thing is not part of our
security model, never has been, and it's simply naive to believe that
it won't have a boatload of easily-reachable holes in it. Which we
*will* get complaints about, if we claim that thus-and-such feature
prevents it. So why bother? Don't give out superuser to people you
don't trust to not do the things you wish they wouldn't.
> I also think that using the GUC system to manage itself is a little
> bit suspect.
Something like contrib/sepgsql would be a better mechanism, perhaps.
regards, tom lane
