[jira] [Commented] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722714#comment-17722714
]
Mohit Ambalkar commented on RANGER-3884:
*Can you try with put request instead of post*
** API :[http://localhost:6080/service/xusers/permission/4]
Json body:
{
"id": 4,
"createDate": "2023-04-26T04:58:41Z",
"updateDate": "2023-05-04T08:48:17Z",
"userId": 21,
"userName" :"temp4",
"owner": "Admin",
"groupPermList": [],
"isAllowed": 1,
"loginId" : "admin",
"module": "Audit",
"updatedBy": "Admin",
"url": "",
"userPermList": [
{
"userId": 21,
"moduleId": 4,
"isAllowed": 1
}
]
}
When we grant audit permission to a new user, an object is created in the
x_module_perm table. When we later make changes to the same user, only the
attribute values are allowed to change. If permission is denied, the value is
set to 0. If permission is granted, the value changes to 1.
However, when we remove the permission, the object with the user ID and module
ID is not deleted from the x_module_perm table. Only the ‘is allowed’ attribute
value is changed. Consequently, when we use a POST method, it checks every time
whether the object with the given user ID and module ID is present or not. This
leads to the following error:
{"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
the module with ID [4]","messageList": [{"name":
"ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
"message": "Error creating duplicate object"}]}
Therefore, can you try using PUT request and see if satisfies your use-case
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId" :
> new_user_username} {code}
> 3. The user will be granted permissions on the Audits module
> 4. Go to the UI, remove the permissions for the user on the Audits module
> 5. Then make a POST request to the same REST endpoint with the same payload.
> Since the user did not have permissions on the Audits module, the user should
> have
> been granted access on the Audits module, but it results in the following
> error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [127] is already assigned
> to the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> Also, the user id in the error message is always user_id_in_payload - 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3884:
--
Assignee: Mohit Ambalkar
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Mohit Ambalkar
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId" :
> new_user_username} {code}
> 3. The user will be granted permissions on the Audits module
> 4. Go to the UI, remove the permissions for the user on the Audits module
> 5. Then make a POST request to the same REST endpoint with the same payload.
> Since the user did not have permissions on the Audits module, the user should
> have
> been granted access on the Audits module, but it results in the following
> error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [127] is already assigned
> to the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> Also, the user id in the error message is always user_id_in_payload - 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4229) Add flag based support for mounting db volume in dev-support scripts
[ https://issues.apache.org/jira/browse/RANGER-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4229: -- Assignee: Mohit Ambalkar > Add flag based support for mounting db volume in dev-support scripts > > > Key: RANGER-4229 > URL: https://issues.apache.org/jira/browse/RANGER-4229 > Project: Ranger > Issue Type: Improvement > Components: build-infra >Reporter: Jai Patel >Assignee: Mohit Ambalkar >Priority: Minor > > Currently, the DB which gets used via dev-support scripts is not mounted to > any local storage. As a result, we lose all data if docker containers are > shutdown and brought up again. > Raising this ticket to have a flag based support for mounting the db volumes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3921:
--
Assignee: Mohit Ambalkar
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: Mohit Ambalkar
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722714#comment-17722714
]
Mohit Ambalkar edited comment on RANGER-3884 at 5/17/23 9:09 AM:
-
*[~abhishek.patil] Can you try with put request instead of post*
** API :[http://localhost:6080/service/xusers/permission/4]
Json body:
{
"id": 4,
"createDate": "2023-04-26T04:58:41Z",
"updateDate": "2023-05-04T08:48:17Z",
"userId": 21,
"userName" :"temp4",
"owner": "Admin",
"groupPermList": [],
"isAllowed": 1,
"loginId" : "admin",
"module": "Audit",
"updatedBy": "Admin",
"url": "",
"userPermList": [
{ "userId": 21, "moduleId": 4, "isAllowed": 1 }
]
}
When we grant audit permission to a new user, an object is created in the
x_module_perm table. When we later make changes to the same user, only the
attribute values are allowed to change. If permission is denied, the value is
set to 0. If permission is granted, the value changes to 1.
However, when we remove the permission, the object with the user ID and module
ID is not deleted from the x_module_perm table. Only the ‘is allowed’ attribute
value is changed. Consequently, when we use a POST method, it checks every time
whether the object with the given user ID and module ID is present or not. This
leads to the following error:
{ "statusCode": 1, "msgDesc": "User with ID [76] is already assigned to the
module with ID [4]", "messageList": [
{ "name": "ERROR_DUPLICATE_OBJECT", "rbKey": "xa.error.duplicate_object",
"message": "Error creating duplicate object" }
]}
Therefore, can you try using PUT request and see if satisfies your use-case
was (Author: JIRAUSER299721):
*Can you try with put request instead of post*
** API :[http://localhost:6080/service/xusers/permission/4]
Json body:
{
"id": 4,
"createDate": "2023-04-26T04:58:41Z",
"updateDate": "2023-05-04T08:48:17Z",
"userId": 21,
"userName" :"temp4",
"owner": "Admin",
"groupPermList": [],
"isAllowed": 1,
"loginId" : "admin",
"module": "Audit",
"updatedBy": "Admin",
"url": "",
"userPermList": [
{
"userId": 21,
"moduleId": 4,
"isAllowed": 1
}
]
}
When we grant audit permission to a new user, an object is created in the
x_module_perm table. When we later make changes to the same user, only the
attribute values are allowed to change. If permission is denied, the value is
set to 0. If permission is granted, the value changes to 1.
However, when we remove the permission, the object with the user ID and module
ID is not deleted from the x_module_perm table. Only the ‘is allowed’ attribute
value is changed. Consequently, when we use a POST method, it checks every time
whether the object with the given user ID and module ID is present or not. This
leads to the following error:
{"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
the module with ID [4]","messageList": [{"name":
"ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
"message": "Error creating duplicate object"}]}
Therefore, can you try using PUT request and see if satisfies your use-case
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Mohit Ambalkar
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId
[jira] [Commented] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723393#comment-17723393
]
Mohit Ambalkar commented on RANGER-3921:
*Ideally column level does not support drop condition*
The policy above applied is inappropriate so try without drop condition which
could satisfy ur use case [~kirbyzhou]
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: Mohit Ambalkar
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723393#comment-17723393
]
Mohit Ambalkar edited comment on RANGER-3921 at 5/18/23 3:00 PM:
-
*Ideally column level does not support drop condition*
The policy above applied is inappropriate so can you try without drop
condition which could satisfy ur use case [~kirbyzhou]
was (Author: JIRAUSER299721):
*Ideally column level does not support drop condition*
The policy above applied is inappropriate so try without drop condition which
could satisfy ur use case [~kirbyzhou]
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: Mohit Ambalkar
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723393#comment-17723393
]
Mohit Ambalkar edited comment on RANGER-3921 at 5/19/23 2:48 PM:
-
Ideally column level does not support drop condition
The policy above applied is inappropriate so can you try without drop
condition which could satisfy ur use case [~kirbyzhou] **
was (Author: JIRAUSER299721):
*Ideally column level does not support drop condition*
The policy above applied is inappropriate so can you try without drop
condition which could satisfy ur use case [~kirbyzhou]
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: Mohit Ambalkar
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725247#comment-17725247
]
Mohit Ambalkar commented on RANGER-3884:
[~abhishek.patil] ,have you had a chance to look into this?
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Mohit Ambalkar
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId" :
> new_user_username} {code}
> 3. The user will be granted permissions on the Audits module
> 4. Go to the UI, remove the permissions for the user on the Audits module
> 5. Then make a POST request to the same REST endpoint with the same payload.
> Since the user did not have permissions on the Audits module, the user should
> have
> been granted access on the Audits module, but it results in the following
> error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [127] is already assigned
> to the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> Also, the user id in the error message is always user_id_in_payload - 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4259) Add flag based support for remote debugging dev-support containers
[ https://issues.apache.org/jira/browse/RANGER-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4259: -- Assignee: Mohit Ambalkar > Add flag based support for remote debugging dev-support containers > -- > > Key: RANGER-4259 > URL: https://issues.apache.org/jira/browse/RANGER-4259 > Project: Ranger > Issue Type: Improvement > Components: build-infra >Reporter: Jai Patel >Assignee: Mohit Ambalkar >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3800) Add unimplemented checkCanSetTableAuthorization and checkCanSetTableProperties methods in trino-plugin
[
https://issues.apache.org/jira/browse/RANGER-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3800:
--
Assignee: Mohit Ambalkar
> Add unimplemented checkCanSetTableAuthorization and
> checkCanSetTableProperties methods in trino-plugin
> --
>
> Key: RANGER-3800
> URL: https://issues.apache.org/jira/browse/RANGER-3800
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 2.3.0
>Reporter: Aakash Nand
>Assignee: Mohit Ambalkar
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-3800-Add-unimplemented-methods-for-trino-plug.patch
>
>
> {color:#de350b}checkCanSetTableAuthorization{color} and
> {color:#de350b}checkCanSetTableProperties{color} methods are not implemented
> in trino-ranger-plugin this gives `AccessDeniedException` when executing
> queries like
>
> {{ALTER TABLE XXX SET AUTHORIZATION}}
>
>
> and
>
> {{ALTER TABLE XXX SET PROPERTIES}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-3800) Add unimplemented checkCanSetTableAuthorization and checkCanSetTableProperties methods in trino-plugin
[
https://issues.apache.org/jira/browse/RANGER-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3800:
--
Assignee: (was: Mohit Ambalkar)
> Add unimplemented checkCanSetTableAuthorization and
> checkCanSetTableProperties methods in trino-plugin
> --
>
> Key: RANGER-3800
> URL: https://issues.apache.org/jira/browse/RANGER-3800
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 2.3.0
>Reporter: Aakash Nand
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-3800-Add-unimplemented-methods-for-trino-plug.patch
>
>
> {color:#de350b}checkCanSetTableAuthorization{color} and
> {color:#de350b}checkCanSetTableProperties{color} methods are not implemented
> in trino-ranger-plugin this gives `AccessDeniedException` when executing
> queries like
>
> {{ALTER TABLE XXX SET AUTHORIZATION}}
>
>
> and
>
> {{ALTER TABLE XXX SET PROPERTIES}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
Mohit Ambalkar created RANGER-4277: -- Summary: Insert query not working on coloumn level access for trino plugin Key: RANGER-4277 URL: https://issues.apache.org/jira/browse/RANGER-4277 Project: Ranger Issue Type: Bug Components: plugins Reporter: Mohit Ambalkar After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. was:After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Priority: Major > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4277: -- Assignee: Mohit Ambalkar > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.15.51 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.08.56 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.14.52 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: (was: Screenshot 2023-06-09 at 2.14.52 PM.png) > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.14.52 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.15.51 PM-1.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: > * Audits: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.17.31 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: > * Audits: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: * Expected behaviour: was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Attachment: Screenshot 2023-06-09 at 2.19.22 PM.png > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Trino version:417 * *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: * Expected behaviour: was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: * Expected behaviour: > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Trino version:417 > * > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Description: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Trino version:417 * *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png|width=2243,height=109! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png|width=949,height=386!* * Query:* * Query Result: * Audits: * Expected behaviour: was: After granting column access on the table, the insert query is not working, and receiving an 'access denied' in the audits. *Trino version:417 * *Actual behaviour:* showing access denied on coloumn level insertion !Screenshot 2023-06-09 at 2.15.51 PM.png! *Policy Created: !Screenshot 2023-06-09 at 2.08.56 PM.png!* * Query:* * Query Result: * Audits: * Expected behaviour: > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Trino version:417 > * > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png|width=2243,height=109! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 > PM.png|width=949,height=386!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4277: --- Labels: Trino (was: ) > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Labels: Trino > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Trino version:417 > * > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png|width=2243,height=109! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 > PM.png|width=949,height=386!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4289) Audits not generated for column masking in Trino
Mohit Ambalkar created RANGER-4289: -- Summary: Audits not generated for column masking in Trino Key: RANGER-4289 URL: https://issues.apache.org/jira/browse/RANGER-4289 Project: Ranger Issue Type: Bug Components: audit Reporter: Mohit Ambalkar After applying the masking policy, the expected output is obtained, but audits for column masking are not being generated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4289) Audits not generated for column masking in Trino
[ https://issues.apache.org/jira/browse/RANGER-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4289: -- Assignee: Mohit Ambalkar > Audits not generated for column masking in Trino > > > Key: RANGER-4289 > URL: https://issues.apache.org/jira/browse/RANGER-4289 > Project: Ranger > Issue Type: Bug > Components: audit >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > > After applying the masking policy, the expected output is obtained, but > audits for column masking are not being generated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4289) Audits not generated for column masking in Trino
[ https://issues.apache.org/jira/browse/RANGER-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4289: --- Description: After applying the masking policy, the expected output is obtained, but audits for column masking are not being generated. *Expected Behavior:* When column masking is applied in Trino, audits should be generated. *Actual Behaviour:* Currently, audits are generated only for SELECT and USE access after applying the masking policy. However, audits are not available for column masking operations. was:After applying the masking policy, the expected output is obtained, but audits for column masking are not being generated. > Audits not generated for column masking in Trino > > > Key: RANGER-4289 > URL: https://issues.apache.org/jira/browse/RANGER-4289 > Project: Ranger > Issue Type: Bug > Components: audit >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > > After applying the masking policy, the expected output is obtained, but > audits for column masking are not being generated. > *Expected Behavior:* When column masking is applied in Trino, audits should > be generated. > *Actual Behaviour:* > Currently, audits are generated only for SELECT and USE access after applying > the masking policy. However, audits are not available for column masking > operations. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4289) Audits not generated for column masking in Trino
[ https://issues.apache.org/jira/browse/RANGER-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar updated RANGER-4289: --- Labels: Trino (was: ) > Audits not generated for column masking in Trino > > > Key: RANGER-4289 > URL: https://issues.apache.org/jira/browse/RANGER-4289 > Project: Ranger > Issue Type: Bug > Components: audit >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Labels: Trino > > After applying the masking policy, the expected output is obtained, but > audits for column masking are not being generated. > *Expected Behavior:* When column masking is applied in Trino, audits should > be generated. > *Actual Behaviour:* > Currently, audits are generated only for SELECT and USE access after applying > the masking policy. However, audits are not available for column masking > operations. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4277: -- Assignee: (was: Mohit Ambalkar) > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Priority: Major > Labels: Trino > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Trino version:417 > * > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png|width=2243,height=109! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 > PM.png|width=949,height=386!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4277) Insert query not working on coloumn level access for trino plugin
[ https://issues.apache.org/jira/browse/RANGER-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733450#comment-17733450 ] Mohit Ambalkar commented on RANGER-4277: Authorization for inserting at the column level is not supported in Trino. > Insert query not working on coloumn level access for trino plugin > - > > Key: RANGER-4277 > URL: https://issues.apache.org/jira/browse/RANGER-4277 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: Mohit Ambalkar >Assignee: Mohit Ambalkar >Priority: Major > Labels: Trino > Attachments: Screenshot 2023-06-09 at 2.08.56 PM.png, Screenshot > 2023-06-09 at 2.14.52 PM.png, Screenshot 2023-06-09 at 2.15.51 PM-1.png, > Screenshot 2023-06-09 at 2.15.51 PM.png, Screenshot 2023-06-09 at 2.17.31 > PM.png, Screenshot 2023-06-09 at 2.19.22 PM.png > > > After granting column access on the table, the insert query is not working, > and receiving an 'access denied' in the audits. > *Trino version:417 > * > *Actual behaviour:* showing access denied on coloumn level insertion > !Screenshot 2023-06-09 at 2.15.51 PM.png|width=2243,height=109! > *Policy Created: !Screenshot 2023-06-09 at 2.08.56 > PM.png|width=949,height=386!* > * Query:* > * Query Result: > * Audits: > * Expected behaviour: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4287) Security zone UI: remove validation that mandates at least one service/resource
[ https://issues.apache.org/jira/browse/RANGER-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Ambalkar reassigned RANGER-4287: -- Assignee: Mohit Ambalkar > Security zone UI: remove validation that mandates at least one > service/resource > --- > > Key: RANGER-4287 > URL: https://issues.apache.org/jira/browse/RANGER-4287 > Project: Ranger > Issue Type: Improvement > Components: admin >Reporter: Madhan Neethiraj >Assignee: Mohit Ambalkar >Priority: Major > > RANGER-4286 removed the restriction that a security zone must have at least > one service and one resource. UI should be updated to remove this validation, > to allow create/update of security zones with no service/resource. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3884:
--
Assignee: Abhishek (was: Mohit Ambalkar)
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Abhishek
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId" :
> new_user_username} {code}
> 3. The user will be granted permissions on the Audits module
> 4. Go to the UI, remove the permissions for the user on the Audits module
> 5. Then make a POST request to the same REST endpoint with the same payload.
> Since the user did not have permissions on the Audits module, the user should
> have
> been granted access on the Audits module, but it results in the following
> error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [127] is already assigned
> to the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> Also, the user id in the error message is always user_id_in_payload - 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Ambalkar reassigned RANGER-3921:
--
Assignee: kirby zhou (was: Mohit Ambalkar)
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: kirby zhou
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.
[
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737598#comment-17737598
]
Mohit Ambalkar commented on RANGER-3921:
[~kirbyzhou] assigning you to check this issue and let me know if you are still
able to reproduce the issue
> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Assignee: kirby zhou
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*;
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true},
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of
> column level, rather than the permission of table level or database level.
>
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy/dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> } ,
> {"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
> "request":{
> "resource":{"elements":{"database":"dummy", "udf":"dummy"}},
>
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop
> dummy for user1"
> },
> "result":{"isAudited":false,"isAllowed":true,"policyId":8}
> } {code}
>
> This doesn't seem reasonable. A user who can not drop UDF, but can drop whole
> database.
>
> Or can someone tell me how to only give users column-level permissions
> without involving table or database?
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3884) POST request to /service/xusers/permission/user API results in ERROR_DUPLICATE_OBJECT error
[
https://issues.apache.org/jira/browse/RANGER-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737601#comment-17737601
]
Mohit Ambalkar commented on RANGER-3884:
[~abhishek.patil] Assigning you to check this issue and let me know if you are
still able to reproduce this issue
> POST request to /service/xusers/permission/user API results in
> ERROR_DUPLICATE_OBJECT error
> ---
>
> Key: RANGER-3884
> URL: https://issues.apache.org/jira/browse/RANGER-3884
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Abhishek
>Priority: Major
>
> When a POST request is made to the url
> \{RANGER_ADMIN_URL}//service/xusers/permission/user to assign permission on a
> module to a user for the first time, the API works as expected and the
> permission is
> assigned to the user on the module.
> But when the permission on the module is removed for the user from the UI,
> and a POST request is made again to assign permission on the same module for
> the same user, it results in the following error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [76] is already assigned to
> the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> *Steps to reproduce:-*
> 1. Create a new user in Ranger Admin
> 2. Make the following POST request using the newly created user's user id and
> username with the following payload
> {code:java|bgColor=#f4f5f7}
> { "userId" : new_user_user_id, "moduleId" : 4, "isAllowed" : 1,
> "userName" : new_user_username, "moduleName" : "Audits", "loginId" :
> new_user_username} {code}
> 3. The user will be granted permissions on the Audits module
> 4. Go to the UI, remove the permissions for the user on the Audits module
> 5. Then make a POST request to the same REST endpoint with the same payload.
> Since the user did not have permissions on the Audits module, the user should
> have
> been granted access on the Audits module, but it results in the following
> error
> {code:java|bgColor=#f4f5f7}
> {"statusCode": 1,"msgDesc": "User with ID [127] is already assigned
> to the module with ID [4]","messageList": [{"name":
> "ERROR_DUPLICATE_OBJECT","rbKey": "xa.error.duplicate_object",
> "message": "Error creating duplicate object"}]} {code}
> Also, the user id in the error message is always user_id_in_payload - 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
