Privileges for functions
От | Peter Eisentraut |
---|---|
Тема | Privileges for functions |
Дата | |
Msg-id | Pine.LNX.4.30.0111131800370.17319-100000@peter.localdomain обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: