Re: has_language_privilege returns incorrect answer for non-superuser

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2012-07-10 at 15:28 -0700, Joe Conway wrote:
>> But historically (and perhaps correctly) these functions have always
>> done the former -- so maybe all we need are some words of warning in
>> the documentation of these functions?

> The second question is much more difficult to answer than the first.
> You could have sepgsql in the way, for example.

> The functions very clearly check whether a privilege is being held, and
> elsewhere it is documented what you can do with these privileges. A
> particular action might very well require multiple privileges.

That's a fair argument, but I think it's reasonable to expect that
(1) the privileges required to do something are easily identified and
can be checked from the SQL level; (2) there's a reasonable amount of
consistency in the behavior for different object types.

In these terms, the example of needing schema usage privilege seems
like a different case from lanpltrusted. We have
has_schema_privilege(), so there's support for queries to probe that
component of privilege; and the issue is common across all object types
that live within schemas. Furthermore, client-side code would probably
need to be aware of the schema-privilege angle anyway, because if you
don't have schema usage privilege on "s", you aren't even going to be
able to name table "s.t" to the has_table_privilege function, at least
not to the name-based variants of it.

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.

Having said that, I do think your argument has some merit with respect
to the internal pg_language_aclcheck() function. That is, I'd want
to see any code changes here made in the has_language_privilege
functions, not at the aclcheck level.

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?

regards, tom lane