[JBoss JIRA] (TEIID-5856) Teiid generate wrong request to salesforce
by Renat Eskenin (Jira)
Renat Eskenin created TEIID-5856:
------------------------------------
Summary: Teiid generate wrong request to salesforce
Key: TEIID-5856
URL: https://issues.jboss.org/browse/TEIID-5856
Project: Teiid
Issue Type: Bug
Components: Salesforce Connector
Environment: spring-boot teiid salesforce-connector
Reporter: Renat Eskenin
Assignee: Steven Hawkins
When i call request to salesforce teiid get very long wrong request and then OOM, because teiid request all data in salesforce object.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (TEIIDSB-141) Add a message to PlatformTransactionManagerAdapter exceptions
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-141:
--------------------------------------
Summary: Add a message to PlatformTransactionManagerAdapter exceptions
Key: TEIIDSB-141
URL: https://issues.jboss.org/browse/TEIIDSB-141
Project: Teiid Spring Boot
Issue Type: Quality Risk
Components: core, datasource
Reporter: Steven Hawkins
Fix For: 1.3.0
The PlatformTransactionManagerAdapter will throw SystemExceptions without a message when attempting to initiate a transaction (non-spring managed). There should be a message that a full transaction manager is required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (TEIID-5855) Columns not found in salesforce object Account
by Renat Eskenin (Jira)
Renat Eskenin created TEIID-5855:
------------------------------------
Summary: Columns not found in salesforce object Account
Key: TEIID-5855
URL: https://issues.jboss.org/browse/TEIID-5855
Project: Teiid
Issue Type: Bug
Components: Salesforce Connector
Environment: spring-boot teiid application
Reporter: Renat Eskenin
Assignee: Steven Hawkins
When i try to select column in table account in salesforce i have fail
I do not get column CreatedDate for this table and may be another columns too.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5798?focusedWorklogId=12448117&page... ]
Steven Hawkins logged work on TEIID-5798:
-----------------------------------------
Author: Steven Hawkins
Created on: 25/Nov/19 5:03 PM
Start Date: 25/Nov/19 5:03 PM
Worklog Time Spent: 3 hours
Issue Time Tracking
-------------------
Remaining Estimate: 3 hours (was: 6 hours)
Time Spent: 3 hours
Worklog Id: (was: 12448117)
> 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
> Time Spent: 3 hours
> Remaining Estimate: 3 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)
5 years
[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 updated TEIID-5798:
----------------------------------
Remaining Estimate: 1 day, 7 hours (was: 3 hours)
> 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
> Time Spent: 3 hours
> Remaining Estimate: 1 day, 7 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)
5 years
[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5798?page=com.atlassian.jira.plugin... ]
Christoph John commented on TEIID-5798:
---------------------------------------
Hello Steven,
I have no preferences in how the new syntax should look like. However, when looking at your example, I am wondering if still sql expressions will be supported in the USING statement. I mean, I currently have something like the following in my policies.
GRANT ON TABLE "my_nutri_diary.NutritionGoal" CONDITION 'NutritionGoal.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))' TO odata;
So this will still work, right?
Best regards,
Christoph
> 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)
5 years
[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:
---------------------------------------
Old syntax example:
{code}
GRANT SELECT,INSERT ON TABLE tbl CONDITION col = user() TO role; -- defaults to CONSTRAINT
New:
{code}
GRANT SELECT,INSERT ON tbl TO role;
CREATE POLICY pname ON tbl FOR SELECT,INSERT TO role USING col = user() WITH CHECK; -- effectively WITH CHECK col = user()
{code}
In creating a new implementation we would need to under the covers do a similar conversion - where the policy name is effectively derived. Another simplification would be to only support a single role target, rather than a role list. That would address creating another container concept for this style of grant and instead we could put the grants directly on the DataPolicyMetadata - the same would go for masks.
The "mixed" from above:
{code}
GRANT SELECT,INSERT,UPDATE,DELETE ON tbl TO role; -- could add an ALL option
CREATE POLICY pname ON tbl FOR INSERT,UPDATE,DELETE TO role USING col = user() WITH CHECK;
{code}
> 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)
5 years
[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 edited comment on TEIID-5798 at 11/25/19 4:09 PM:
-----------------------------------------------------------------
Old syntax example:
{code}
GRANT SELECT,INSERT ON TABLE tbl CONDITION col = user() TO role; -- defaults to CONSTRAINT
{code}
New:
{code}
GRANT SELECT,INSERT ON tbl TO role;
CREATE POLICY pname ON tbl FOR SELECT,INSERT TO role USING col = user() WITH CHECK; -- effectively WITH CHECK col = user()
{code}
In creating a new implementation we would need to under the covers do a similar conversion - where the policy name is effectively derived. Another simplification would be to only support a single role target, rather than a role list. That would address creating another container concept for this style of grant and instead we could put the grants directly on the DataPolicyMetadata - the same would go for masks.
The "mixed" from above:
{code}
GRANT SELECT,INSERT,UPDATE,DELETE ON tbl TO role; -- could add an ALL option
CREATE POLICY pname ON tbl FOR INSERT,UPDATE,DELETE TO role USING col = user() WITH CHECK;
{code}
was (Author: shawkins):
Old syntax example:
{code}
GRANT SELECT,INSERT ON TABLE tbl CONDITION col = user() TO role; -- defaults to CONSTRAINT
New:
{code}
GRANT SELECT,INSERT ON tbl TO role;
CREATE POLICY pname ON tbl FOR SELECT,INSERT TO role USING col = user() WITH CHECK; -- effectively WITH CHECK col = user()
{code}
In creating a new implementation we would need to under the covers do a similar conversion - where the policy name is effectively derived. Another simplification would be to only support a single role target, rather than a role list. That would address creating another container concept for this style of grant and instead we could put the grants directly on the DataPolicyMetadata - the same would go for masks.
The "mixed" from above:
{code}
GRANT SELECT,INSERT,UPDATE,DELETE ON tbl TO role; -- could add an ALL option
CREATE POLICY pname ON tbl FOR INSERT,UPDATE,DELETE TO role USING col = user() WITH CHECK;
{code}
> 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)
5 years
[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 edited comment on TEIID-5798 at 11/25/19 3:58 PM:
-----------------------------------------------------------------
row based security based off of: https://www.postgresql.org/docs/9.5/sql-createpolicy.html
would typically look like named policies:
CREATE POLICY name ON table_name FOR operations TO role list USING expression
So this would need to be tracked separately from the current notion of unnamed grants. Teiid has a simple notion of constraint, which is expressed by pg as the WITH CHECK expression - which is valid for both insert and update. We could of course simplify if needed to just allowing WITH CHECK to be specified without an expression if a USING expression is specified.
We would also have support alter/drop policy, and likely would not require the use of an alter ... ENABLE ROW LEVEL SECURITY statement.
Column masking has several pg extensions, but no built-in support. The relevant doc for db2: https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/seca/src/tpc...
It shows a similar paradigm - all masks are named entities - but it also includes some notion of enabled/disabled directly in the statement. Here as well we would likely not carry forward a specific enable/disable. Comparing to current teiid support, DB2 has a limitation of only one mask per column. The Teiid logic will use the order concept to create precedence. Also there is no assignment to roles with the DB2 statement - it would be embedded in the mask expression - case when role ... This however makes it hard to separate the effects of a single role. So we would probably want to add both an ORDER clause and a role assignment TO clause.
So the proposal would be to add a POLICY (which we could possibly also allow the term ROW PERMISSION for consistency in teiid), and MASK concept with CREATE (roughly outlined above), ALTER, and DROP support. These would probably need to be top level db entities (siblings to DataPolicyMetadata) or we would need to introduce a new top level container for all of the security related stuff. Much of the implementation logic would be similar, but there is more work to do in building the row-level expression (could be multiple policies per role), determine what the contraint/check expression should be, and in building the mask (unless we restrict to a single mask per role).
Thoughts?
Unfortunately given the work involved and holidays time coming up, this seems like it could push 13.0 into next year.
was (Author: shawkins):
row based security based off of: https://www.postgresql.org/docs/9.5/sql-createpolicy.html
would typically look like named policies:
CREATE POLICY name ON table_name FOR operations TO role list WITH expression
So this would need to be tracked separately from the current notion of unnamed grants. Teiid has a simple notion of constraint, which is express by pg as CHECK expression - which is valid for both insert and update. We could of course simplify if needed to just allowing CHECK to be specified without an expression.
We would also have support alter/drop policy, and likely would not require the use of an alter ... ENABLE ROW LEVEL SECURITY statement.
Column masking has several pg extensions, but no built-in support. The relevant doc for db2: https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/seca/src/tpc...
It shows a similar paradigm - all masks are named entities - but it also includes some notion of enabled/disabled directly in the statement. Here as well we would likely not carry forward a specific enable/disable. Comparing to current teiid support, DB2 has a limitation of only one mask per column. The Teiid logic will use the order concept to create precedence. Also there is no assignment to roles with the DB2 statement - it would be embedded in the mask expression - case when role ... This however makes it hard to separate the effects of a single role. So we would probably want to add both an ORDER clause and a role assignment TO clause.
So the proposal would be to add a POLICY (which we could possibly also allow the term ROW PERMISSION for consistency in teiid), and MASK concept with CREATE (roughly outlined above), ALTER, and DROP support. These would probably need to be top level db entities (siblings to DataPolicyMetadata) or we would need to introduce a new top level container for all of the security related stuff. Much of the implementation logic would be similar, but there is more work to do in building the row-level expression (could be multiple policies per role), determine what the contraint/check expression should be, and in building the mask (unless we restrict to a single mask per role).
Thoughts?
Unfortunately given the work involved and holidays time coming up, this seems like it could push 13.0 into next year.
> 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)
5 years