Thought the ticket is specific to functions, the implementation of that privilege is also applicable for switch db privilege. Hence the two are combined into the single patch. I will log a separate ticket to track switch db and close it with reference to this one.
- Implicit privilege for create/drop temp functions for a user that has access to any object in the system
- Implicit privilege for use <db> to any user that access to any object in that database
+ An authz config level option to allow any user to access the 'default' if you have access to any object in the system. This is added since its common for hive application to connect to 'default' at the start. without this config, the admins will need add workaround (eg a dummy object just to simulate a connect privilege on default db) for 'use default' to work for every user.
+ The default for the above configuration is to allow 'use default'
- Implemented as an implicit connect privilege that checks if the the user has privilege on any object under the given hierarchy.
- Policy handler allows Authorizable.* to match any authorizable object of the given type
The wiki docs will be updated to reflect the changes and configs after the patch is committed.
Added tests for various use <db> scenarios
Added tests for various create/drop function scenarios
Loading file attachments...
Since create/drop function require ALL on server, I don't fully understand why we are sending db=* down to the policy ...
At this place in the code, we know that: policyPart.getKey().equalsIgnoreCase(requestPart.getKey()) is true. See assertion directly above if statement.
The requesting coming with * means that "do we have access to any object"?
Review request changed
Per latest discussion -
- Use URI privileges on Jar for create function privilege.
- Also support system property placeholders in the
- changes to policy file to handle
- extract jar for the given UDF class name.
It's possible for getCodeSource to return null. It's also possible for getPath to return an empty string. I think that both these cases should be handled by throwing an exception with a good error message so we can different these cases should we see them in the wild.