[ https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394149#comment-16394149 ]
Piotr Bojko edited comment on CALCITE-2194 at 3/10/18 6:01 PM: --------------------------------------------------------------- There is no INDIRECT_SELECT in the code -, it is already removed now. As for the Oracle example - it is solely on the implementation of AuthorizationGuardFactory now. If someone would create some kind OracleLikeAuthorizaionGuardFactory then the access to schemas would be exactly like you've said. Someone can implement other authorization schemes. What worries me is that your wanted auth scheme requires new relation to schema - ownership. Having that said - I think that AuthorizationGuardFactory should be declared not on the schema level but rather root schema, and gives it not only the responsibility to create a decision maker about accessing to it (guards) but also the responsibility to define ownership on each schema. With such design AuthorizatonFactory could be able to handle ownership and roles or access rights in each schema declared in a file or created under a connection. Just a quick scratch here: {code:json} { "version": "1.0", "defaultSchema": "ENHANCED", "authorization": { "factory": "org.apache.calcite.access.PrincipalWithOwnershipAuthFactory", "operand": {} }, "schemas": [ { "name": "CHINOOK", "type": "jdbc", "jdbcDriver": "org.hsqldb.jdbc.JDBCDriver", "jdbcUrl": "jdbc:hsqldb:res:chinook", "jdbcUser": "sa", "jdbcPassword": "", "authConfig": { "sa": "SELECT" } }, { "name": "ENHANCED", "type": "custom", "factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory", "operand": {}, "authConfig": { "sa": "OWNER", "user" : "SELECT" }, "tables": [ ... ] } ] } {code} With such design - user defines his AuthorizationFactory on root level. This factory will handle creating guards on each schema using authConfig. [~julianhyde] your particular preference (which I agree is a standard and a cool addition to calcite which would cover vast area of application, even mine) and defining ownership or any other information it needs to resolve authorization to schema. In an example above PrincipalWithOwnershipAuthFactory will be responsible for handling SELECT/INSERT/etc rights and OWNER role (not built in to calcite but built in to this factory). What do you think about above example? I can try to redesign the contribution to this particular example, which can be more generic. I can provide your wanted auth scheme (with a notion of an ownership) and present full usage in chinook example/tests. EDIT: already shipped that, see chinook.json as an example, ownership added. Please note that the algorithm in PrincipalBasedAuthorization class covers what have you said but additionally covers some corner cases, so you may have some doubts there, hopefully minor :) was (Author: ptrbojko): There is no INDIRECT_SELECT in the code -, it is already removed now. As for the Oracle example - it is solely on the implementation of AuthorizationGuardFactory now. If someone would create some kind OracleLikeAuthorizaionGuardFactory then the access to schemas would be exactly like you've said. Someone can implement other authorization schemes. What worries me is that your wanted auth scheme requires new relation to schema - ownership. Having that said - I think that AuthorizationGuardFactory should be declared not on the schema level but rather root schema, and gives it not only the responsibility to create a decision maker about accessing to it (guards) but also the responsibility to define ownership on each schema. With such design AuthorizatonFactory could be able to handle ownership and roles or access rights in each schema declared in a file or created under a connection. Just a quick scratch here: {code:json} { "version": "1.0", "defaultSchema": "ENHANCED", "authorization": { "factory": "org.apache.calcite.access.PrincipalWithOwnershipAuthFactory", "operand": {} }, "schemas": [ { "name": "CHINOOK", "type": "jdbc", "jdbcDriver": "org.hsqldb.jdbc.JDBCDriver", "jdbcUrl": "jdbc:hsqldb:res:chinook", "jdbcUser": "sa", "jdbcPassword": "", "authConfig": { "sa": "SELECT" } }, { "name": "ENHANCED", "type": "custom", "factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory", "operand": {}, "authConfig": { "sa": "OWNER", "user" : "SELECT" }, "tables": [ ... ] } ] } {code} With such design - user defines his AuthorizationFactory on root level. This factory will handle creating guards on each schema using authConfig. [~julianhyde] your particular preference (which I agree is a standard and a cool addition to calcite which would cover vast area of application, even mine) and defining ownership or any other information it needs to resolve authorization to schema. In an example above PrincipalWithOwnershipAuthFactory will be responsible for handling SELECT/INSERT/etc rights and OWNER role (not built in to calcite but built in to this factory). What do you think about above example? I can try to redesign the contribution to this particular example, which can be more generic. I can provide your wanted auth scheme (with a notion of an ownership) and present full usage in chinook example/tests. > Ability to hide a schema > ------------------------ > > Key: CALCITE-2194 > URL: https://issues.apache.org/jira/browse/CALCITE-2194 > Project: Calcite > Issue Type: New Feature > Components: core > Affects Versions: 1.16.0 > Reporter: Piotr Bojko > Assignee: Piotr Bojko > Priority: Minor > > See: > [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E] > I've looked into the core and the notion of an user could be hard to achieved > now. > Though, I am able to implement the "hidden schema" feature through following > changes: > # JsonSchema - add a holder for the feature, boolean flag or flags field > with enum (CACHED which now exists as a separate flag - some deprecation > could be needed, HIDDEN) > # CalciteSchema - pass through of a flag > # RelOptSchema - pass through of a flag > # CalciteCatalogReader - pass through of a flag > # Other derivatives of RelOptSchema - mocked value, false > # RelOptTable and impl - pass through of a flag > # SqlValidatorImpl - validation whether object from hidden schema is used > (in the same places like validateAccess) > # ViewTableMacro.apply -> Schemas.analyzeView -> > CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ -> > CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build > SqlValidatorImpl which has the check from point 7 disabled- > Such feature could be useful for end users. > If the solution is ok - I can contribute it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)