On tor, 2012-07-12 at 01:40 -0400, Tom Lane wrote:
> So it seems arguably reasonable to me for has_language_privilege()
> to take superuserness and lanpltrusted into account, without thereby
> concluding that other privilege() functions must do more than they
> do today. If we don't want it to do that, then I think we ought to
> offer some other function that *does* consider those things ... but
> I'm not seeing the value of separating it out.
As long as we're spending time on this, I'd propose getting rid of
lanplistrusted, at least for access checking. Instead, just don't
install USAGE privileges by default for those languages.
The reason is that there is value in having a role that can deploy
schemas, possibly containing functions in untrusted languages, without
having to be a full superuser. Just like you can have a user that can
create roles without being a superuser.
> The sepgsql point is worth discussing too. I have not been paying
> close attention to the sepgsql patches, but I have the distinct
> impression that they create a non-examinable privilege barrier,
> ie there's no way to inquire whether you have the privilege to do
> X except by actually trying it. Is that really the way we want
> things to go?
Well, that's how SELinux works too. You can inspect the labels and all
that, but nobody really knows what's going to happen until you try it.
Which is ultimately the recommended way anyway. has_*_privilege is a
bit like the access() function, which has caveats associated with it.