Peter Eisentraut <pete...@gmx.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
