[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5798?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5798:
---------------------------------------
The easier foundational issues are now out of the way. With more reflection I'm inclined to either address by expanding upon the single statement approach or by separating out our handling of row based security / masking. The rationale is that it's either the easiest / least breaking change, or it's more consistent with other vendors. Any thoughts / votes?
> Mixed PERMISSION GRANTS
> -----------------------
>
> Key: TEIID-5798
> URL: https://issues.jboss.org/browse/TEIID-5798
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.0
>
> Original Estimate: 6 hours
> Remaining Estimate: 6 hours
>
> Hello,
> I am currently trying to set a set of permissions on a table/view. Hence a condition on INSERT,UPDATE,DELETE and an unconditioned SELECT.
> However, it seems that conditioned and unconditioned GRANT statements do not work together.
> {code}
> GRANT INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' TO odata;
> GRANT SELECT ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" TO odata;
> REVOKE ALTER,EXECUTE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" FROM odata;
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-135) top in odata query is not working
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-135?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-135:
----------------------------------------
> But can you explain, please. For make $top work we need in odata requests always set $orderby?
No, you do not need an explicit order by. The entities are always implicit ordered by id, so for a top an order by is effectively being pushed down already. Then by default the salesforce translator is indicating that order by is not supported, so the sorting is performed in the engine. As a workaround there is a translator property, supportsOrderBy, that can be set to true in the vdb or in your application properties.
> top in odata query is not working
> ---------------------------------
>
> Key: TEIIDSB-135
> URL: https://issues.jboss.org/browse/TEIIDSB-135
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: OData
> Affects Versions: 1.2.0
> Environment: teiid-spring-boot+spring-odata teiid+spring-data-salesforce
> Reporter: Renat Eskenin
> Priority: Major
>
> When we call simple request as
> salesforce-odata-facade/odata/salesforce/Product_License__c?$top=1&$select=Id
> request processing time is 1min. But this request processing by simple SOAP SOQL request is ~150ms.
> I think this do because teiid select all objects by ignoring top in request.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-135) top in odata query is not working
by Renat Eskenin (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-135?page=com.atlassian.jira.plugi... ]
Renat Eskenin commented on TEIIDSB-135:
---------------------------------------
I do not have access to https://issues.jboss.org/browse/MMX-2585
But can you explain, please. For make $top work we need in odata requests always set $orderby?
> top in odata query is not working
> ---------------------------------
>
> Key: TEIIDSB-135
> URL: https://issues.jboss.org/browse/TEIIDSB-135
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: OData
> Affects Versions: 1.2.0
> Environment: teiid-spring-boot+spring-odata teiid+spring-data-salesforce
> Reporter: Renat Eskenin
> Priority: Major
>
> When we call simple request as
> salesforce-odata-facade/odata/salesforce/Product_License__c?$top=1&$select=Id
> request processing time is 1min. But this request processing by simple SOAP SOQL request is ~150ms.
> I think this do because teiid select all objects by ignoring top in request.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-135) top in odata query is not working
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-135?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-135:
----------------------------------------
Quite a while ago order by support was turned off by default for the salesforce translator: https://issues.jboss.org/browse/MMX-2585
The workaround is to enable order by with a translator override property - but you may hit the original issue that not all salesforce types are sortable.
This issue could be to make the old fix more targeted - that is leave order by enabled, but selective identify types/columns that cannot be sorted.
> top in odata query is not working
> ---------------------------------
>
> Key: TEIIDSB-135
> URL: https://issues.jboss.org/browse/TEIIDSB-135
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: OData
> Affects Versions: 1.2.0
> Environment: teiid-spring-boot+spring-odata teiid+spring-data-salesforce
> Reporter: Renat Eskenin
> Priority: Major
>
> When we call simple request as
> salesforce-odata-facade/odata/salesforce/Product_License__c?$top=1&$select=Id
> request processing time is 1min. But this request processing by simple SOAP SOQL request is ~150ms.
> I think this do because teiid select all objects by ignoring top in request.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-135) top in odata query is not working
by Renat Eskenin (Jira)
Renat Eskenin created TEIIDSB-135:
-------------------------------------
Summary: top in odata query is not working
Key: TEIIDSB-135
URL: https://issues.jboss.org/browse/TEIIDSB-135
Project: Teiid Spring Boot
Issue Type: Bug
Components: OData
Affects Versions: 1.2.0
Environment: teiid-spring-boot+spring-odata teiid+spring-data-salesforce
Reporter: Renat Eskenin
When we call simple request as
salesforce-odata-facade/odata/salesforce/Product_License__c?$top=1&$select=Id
request processing time is 1min. But this request processing by simple SOAP SOQL request is ~150ms.
I think this do because teiid select all objects by ignoring top in request.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5841) Authorization of table name that contain .
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5841?focusedWorklogId=12448073&page... ]
Steven Hawkins logged work on TEIID-5841:
-----------------------------------------
Author: Steven Hawkins
Created on: 11/Nov/19 4:02 PM
Start Date: 11/Nov/19 4:02 PM
Worklog Time Spent: 6 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 6 hours)
Time Spent: 6 hours
Worklog Id: (was: 12448073)
> Authorization of table name that contain .
> ------------------------------------------
>
> Key: TEIID-5841
> URL: https://issues.jboss.org/browse/TEIID-5841
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.0
>
> Original Estimate: 6 hours
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> We have a long standing issue with the permission system mostly due to the initial api design - we only pass fully qualified names to the policy decider in the from of schema.table. If the table name contains '.' the policy decider simplistically walks up each segment - which effectively introduces inappropriate checks.
> For example if we have:
> view "a.b" and view "a", when we check permissions for "a.b" we'll first check for the a.b resource, then the a resource - which is not appropriate. This behavior in part was likely initially due to multi-schema import scenarios, such that the imported table names would be qualified by source schema name. Then you could add permissions against that partially qualified name teiidSchema.sourceSchema. That will no longer be possible if we implement TEIID-5840
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5841) Authorization of table name that contain .
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5841?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5841.
-----------------------------------
Resolution: Done
Went ahead and made preliminary doc updates. It will likely be expanded after TEIID-5798
> Authorization of table name that contain .
> ------------------------------------------
>
> Key: TEIID-5841
> URL: https://issues.jboss.org/browse/TEIID-5841
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.0
>
> Original Estimate: 6 hours
> Remaining Estimate: 6 hours
>
> We have a long standing issue with the permission system mostly due to the initial api design - we only pass fully qualified names to the policy decider in the from of schema.table. If the table name contains '.' the policy decider simplistically walks up each segment - which effectively introduces inappropriate checks.
> For example if we have:
> view "a.b" and view "a", when we check permissions for "a.b" we'll first check for the a.b resource, then the a resource - which is not appropriate. This behavior in part was likely initially due to multi-schema import scenarios, such that the imported table names would be qualified by source schema name. Then you could add permissions against that partially qualified name teiidSchema.sourceSchema. That will no longer be possible if we implement TEIID-5840
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5840) Add validation of grant / revoke targets
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5840?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5840.
-----------------------------------
Resolution: Done
Updated the metadatavalidator - as this needs to be after import to successfully know the possible targets - to resolve the targets of permissions.
> Add validation of grant / revoke targets
> ----------------------------------------
>
> Key: TEIID-5840
> URL: https://issues.jboss.org/browse/TEIID-5840
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.0
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> We should be more pedantic about the targets of GRANT/REVOKE as they now specify both object type and name. Currently a grant against a non-existent target will still succeed - this is hold over from the loosely coupled permissioning model from designer.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5840) Add validation of grant / revoke targets
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5840?focusedWorklogId=12448072&page... ]
Steven Hawkins logged work on TEIID-5840:
-----------------------------------------
Author: Steven Hawkins
Created on: 11/Nov/19 3:15 PM
Start Date: 11/Nov/19 3:15 PM
Worklog Time Spent: 5 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 4 hours)
Time Spent: 5 hours
Worklog Id: (was: 12448072)
> Add validation of grant / revoke targets
> ----------------------------------------
>
> Key: TEIID-5840
> URL: https://issues.jboss.org/browse/TEIID-5840
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.0
>
> Original Estimate: 4 hours
> Time Spent: 5 hours
> Remaining Estimate: 0 minutes
>
> We should be more pedantic about the targets of GRANT/REVOKE as they now specify both object type and name. Currently a grant against a non-existent target will still succeed - this is hold over from the loosely coupled permissioning model from designer.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (TEIID-5845) NullPointerException when running query
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5845?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5845:
---------------------------------------
Please confirm that this occurs against a later version, 11+, as more than likely it is out of date.
If it still occurs, and only against a view and not a regular table, then please provide the view definition or the showplan debug log so that we can see how that looks.
> NullPointerException when running query
> ---------------------------------------
>
> Key: TEIID-5845
> URL: https://issues.jboss.org/browse/TEIID-5845
> Project: Teiid
> Issue Type: Bug
> Reporter: Alexandra Gaspar
> Assignee: Steven Hawkins
> Priority: Minor
>
> Running a query of the following format causes a NullPointerException :
> {code:java}
> SELECT col1, col2, col3
> FROM TeiidView1
> WHERE col2 = 'value'
> GROUP BY col1
> ORDER BY NVL(col3, 0) DESC
> {code}
>
> If adding adding a limit at the end of the query, it runs successfully. Similarly, removing the `NVL` function also results in the query returning results without any errors.
> This is the stack trace:
> {noformat}
> TEIID30019 Unexpected exception for request b+HUTj++9EfY.0: java.lang.NullPointerException
> at org.teiid.query.optimizer.relational.rules.RulePlanSorts.checkForProjectOptimization(RulePlanSorts.java:333) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.query.optimizer.relational.rules.RulePlanSorts.optimizeSorts(RulePlanSorts.java:91) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.query.optimizer.relational.rules.RulePlanSorts.execute(RulePlanSorts.java:69) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:1007) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:232) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:186) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:453) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:481) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:657) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:338) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:282) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-9.1.5.jar:9.1.5]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-9.1.5.jar:9.1.5]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months