[
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394149#comment-16394149
]
Piotr Bojko commented on CALCITE-2194:
--------------------------------------
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)
