Today I resolved to leave major redesigns aside and implement privileges
for functions using the existing mechanisms. I added a proacl column of
type aclitem[] to pg_proc (internally, the EXECUTE privilege uses the same
bit as SELECT), added a permission check in the executor, and that was it.
Getting the GRANT and REVOKE commands to work will take a bit still, but
as long as you're willing to tweak proacl manually you have a working
system.
So here are a couple of details to think about:
* I didn't bother about operators -- an operator has the same permission
as the underlying function. This is the most sensible thing to do, IMHO,
but in some cases it would make for an unpretty user interface. If
requested I could imagine making a GRANT ON OPERATOR command that still
changes the permissions of the function.
* How to handle built-in functions? For tables we have a hack that treats
names beginning with "pg_" specially, which obviously won't work for
functions. Option 1 is to treat at NULL proacl as world access, option 2
is to initialize all builtin proacls with explicit world access.
However, option 1 would introduce a weird behavior that the first GRANT
command will mysteriously revoke the world access, similar to some bug
we've already had with relation acls. I'm currently giving all functions
with oids under 16384 a free pass, which is fastest but not really
satisfactory.
* Backward compatibility: If we go for option 1 above then there are no
backward compatibility problems. In other cases we might have some schemas
which won't work anymore without explicitly granting privileges on
functions.
* For tables, we have the rule that tables introduced into the query by a
rule have their permissions checked as the user that created the rule. I
don't see this easily possible for functions. Moreover, it might not even
make sense when an operator is the join operator between two tables.
--
Peter Eisentraut peter_e@gmx.net
