[jira] [Created] (RANGER-4716) Revoke on table doesnot update ranger policy if grant was executed on specific columns of table
suja s created RANGER-4716: -- Summary: Revoke on table doesnot update ranger policy if grant was executed on specific columns of table Key: RANGER-4716 URL: https://issues.apache.org/jira/browse/RANGER-4716 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s On validation with RANGER-4585 fix, When grant command is invoked separately for different users, even though it is for same resource and same set of permissions, different policies are created >From impala-shell Perform grant command execution with set of columns c1,c2 for table t1 for user u1 Perform grant command execution with set of columns c1,c2 for table t1 for user u2 This creates 2 policies even though resources and access types are same -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4716) Revoke on table doesnot update ranger policy if grant was executed on specific columns of table
[ https://issues.apache.org/jira/browse/RANGER-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s updated RANGER-4716: --- Description: On validation with RANGER-4585 fix, STEPS TO REPRODUCE: >From impala-shell Perform grant command execution with set of columns c1,c2 for table t1 for user u1 Perform revoke command execution on table t1 for user u1 CURRENT BEHAVIOUR: Revoke execution is shown as successful but ranger policy is not updated tp remove the user from policy for [db/table] EXPECTED BEHAVIOUR: Revoke on table should be able to update the ranger policy to remove user permissions was: On validation with RANGER-4585 fix, When grant command is invoked separately for different users, even though it is for same resource and same set of permissions, different policies are created >From impala-shell Perform grant command execution with set of columns c1,c2 for table t1 for user u1 Perform grant command execution with set of columns c1,c2 for table t1 for user u2 This creates 2 policies even though resources and access types are same > Revoke on table doesnot update ranger policy if grant was executed on > specific columns of table > --- > > Key: RANGER-4716 > URL: https://issues.apache.org/jira/browse/RANGER-4716 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Priority: Major > > On validation with RANGER-4585 fix, > STEPS TO REPRODUCE: > From impala-shell > Perform grant command execution with set of columns c1,c2 for table t1 for > user u1 > Perform revoke command execution on table t1 for user u1 > CURRENT BEHAVIOUR: > Revoke execution is shown as successful but ranger policy is not updated tp > remove the user from policy for [db/table] > EXPECTED BEHAVIOUR: > Revoke on table should be able to update the ranger policy to remove user > permissions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4715) Multiple policies created for grant on same set of columns for different users
suja s created RANGER-4715: -- Summary: Multiple policies created for grant on same set of columns for different users Key: RANGER-4715 URL: https://issues.apache.org/jira/browse/RANGER-4715 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s On validation with RANGER-4585 fix, When grant command is invoked separately for different users, even though it is for same resource and same set of permissions, different policies are created >From impala-shell Perform grant command execution with set of columns c1,c2 for table t1 for user u1 Perform grant command execution with set of columns c1,c2 for table t1 for user u2 This creates 2 policies even though resources and access types are same -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4714) Issue with delegate admin and with grant option policy
suja s created RANGER-4714: -- Summary: Issue with delegate admin and with grant option policy Key: RANGER-4714 URL: https://issues.apache.org/jira/browse/RANGER-4714 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s Assignee: Sanket Shelar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4713) Alter view needs additional select permission on db which is not required for create view
suja s created RANGER-4713: -- Summary: Alter view needs additional select permission on db which is not required for create view Key: RANGER-4713 URL: https://issues.apache.org/jira/browse/RANGER-4713 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Create db dbfortest Create table tablefortest under dbfortest (create table dbfortest.tablefortest(id int, name1 string, name2 string)) Insert rows into dbfortest.tablefortest User u1 has select access on tablefortest via ranger policy[db=dbfortest, table=tablefortest, column=*] - policy P1 User u1 has create and alter permissions via ranger policy [db=dbfortest, table=viewfortest, column=*] - policy P2 Connect to beeline as user u1 and execute command 'create view dbfortest.viewfortest as select id,name1 from dbfortest.tablefortest' View creation is successful, Ranger access audits show that policy P1 granted select on tablefortest and policy P2 granted create on viewfortest Execute command 'alter view dbfortest.viewfortest as select id,name2 from dbfortest.tablefortest'. CURRENT BEHAVIOUR: Alter view command fails with access denied error for user not having select permissions on database dbfortest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4712) RangerHiveAuthorizer throws exception for show grant ALL command
suja s created RANGER-4712: -- Summary: RangerHiveAuthorizer throws exception for show grant ALL command Key: RANGER-4712 URL: https://issues.apache.org/jira/browse/RANGER-4712 Project: Ranger Issue Type: Bug Components: plugins Reporter: suja s STEPS TO REPRODUCE: User u1 exists on ranger side and has policy configured for all access for table t1 Create a role r1 with u1 part of r1 Create a hive table and grant access to user u1 As user u1, connect to beeline and execute command 'show grant user u1 on table t1' As user u1, connect to beeline and execute command 'show grant role r1 on table t1' command syntax: SHOW GRANT [principal_specification] ON (ALL | [TABLE] table_or_view_name); CURRENT BEHAVIOUR: Show grant command works fine for table option and not for ALL option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4711) Show grant on table command is not audited by ranger
suja s created RANGER-4711: -- Summary: Show grant on table command is not audited by ranger Key: RANGER-4711 URL: https://issues.apache.org/jira/browse/RANGER-4711 Project: Ranger Issue Type: Bug Components: audit Reporter: suja s -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4710) HS2 logs having huge number of WARN logs from RangerHiveAuthorizer regarding connection to HMS for fetching hive object owner
[ https://issues.apache.org/jira/browse/RANGER-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s updated RANGER-4710: --- Description: CURRENT BEHAVIOUR: HS2 logs having huge number of WARN logs from RangerHiveAuthorizer indicating connection to HMS for fetching hive object owner EXPECTED BEHAVIOUR: Reduce the log level to DEBUG if this is expected behaviour. was: CURRENT BEHAVIOUR: HS2 logs having huge number of WARN logs from RangerHiveAuthorizer indicating connection to HMS for fetching hive object owner > HS2 logs having huge number of WARN logs from RangerHiveAuthorizer regarding > connection to HMS for fetching hive object owner > - > > Key: RANGER-4710 > URL: https://issues.apache.org/jira/browse/RANGER-4710 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: suja s >Priority: Major > > CURRENT BEHAVIOUR: > HS2 logs having huge number of WARN logs from RangerHiveAuthorizer indicating > connection to HMS for fetching hive object owner > EXPECTED BEHAVIOUR: > Reduce the log level to DEBUG if this is expected behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4710) HS2 logs having huge number of WARN logs from RangerHiveAuthorizer regarding connection to HMS for fetching hive object owner
suja s created RANGER-4710: -- Summary: HS2 logs having huge number of WARN logs from RangerHiveAuthorizer regarding connection to HMS for fetching hive object owner Key: RANGER-4710 URL: https://issues.apache.org/jira/browse/RANGER-4710 Project: Ranger Issue Type: Bug Components: plugins Reporter: suja s CURRENT BEHAVIOUR: HS2 logs having huge number of WARN logs from RangerHiveAuthorizer indicating connection to HMS for fetching hive object owner -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4709) Set role command is not audited by ranger
suja s created RANGER-4709: -- Summary: Set role command is not audited by ranger Key: RANGER-4709 URL: https://issues.apache.org/jira/browse/RANGER-4709 Project: Ranger Issue Type: Bug Components: audit Reporter: suja s STEPS TO REPRODUCE: Create roles r1, r2 via hive beeline. Assign role r1 to user u1 Connect to beeline as user u1 Execute command 'set role none'. Operation is succesful. Execute command 'set role r2'. Operation fails as u1 is not part of r2. Execute command 'set role r1'. Operation is succesful. Inspect access audit logs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4708) Grant/revoke commands honoured by Ranger policy
suja s created RANGER-4708: -- Summary: Grant/revoke commands honoured by Ranger policy Key: RANGER-4708 URL: https://issues.apache.org/jira/browse/RANGER-4708 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Create table t1 in hive As user u1, perform invoke grant/revoke commands via hive beeline for table t1 Inspect access audit logs corresponding to grant/revoke operations User u1 can have admin or USER role on ranger side. CURRENT BEHAVIOUR: Logs show that the grant or revoke operation is allowed by default ranger-hive policy 'default database tables columns' (public group has create permissions on resource=[default/*/*]) EXPECTED BEHAVIOUR: Grant/Revoke operations are admin operations and should be performed by a user having admin role on ranger side. The permissions shouldnot not be granted via ranger policy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4707) Revoke grant option for command removes the user privilege from ranger policy
suja s created RANGER-4707: -- Summary: Revoke grant option for command removes the user privilege from ranger policy Key: RANGER-4707 URL: https://issues.apache.org/jira/browse/RANGER-4707 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: User u1 is a ranger admin, also configured as service admin user for hive. Users u2 and u3 have USER role on ranger side. Create a hive table tl1 as user u1. User u1 has full permissions on tl1 via ranger policy. As user u1, execute hive beeline command 'grant select on tl1 to user u2' Ranger grant policy is created with user u2 added with select access type. As user u1, execute hive beeline command 'grant select on tl1 to user u3 with grant option' Ranger grant policy is updated with user u3 added with select access type and delegate admin flag set. As user u1, execute hive beeline command 'revoke select on table tl1 from user u2' User u2 is removed from ranger grant policy As user u1, execute hive beeline command 'revoke grant option for select on table tl1 from user u3' CURRENT BEHAVIOUR: User u3 is removed from ranger grant policy EXPECTED BEHAVIOUR: Revoke grant option should retain the privilege for user and remove only with grant permission, ie access type permission should still exist for user in ranger policy and delegate admin permission should be removed. >From hive documentation: If a user is granted a privilege WITH GRANT OPTION on a table or view, then the user can also grant/revoke privileges of other users and roles on those objects. As of Hive 0.14.0, the grant option for a privilege can be removed while still keeping the privilege by using REVOKE GRANT OPTION FOR -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4706) Hive Show principals /Show roles commands not working for ranger admin user
[ https://issues.apache.org/jira/browse/RANGER-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s updated RANGER-4706: --- Summary: Hive Show principals /Show roles commands not working for ranger admin user (was: Hive Show principals command not working for ranger admin user) > Hive Show principals /Show roles commands not working for ranger > admin user > - > > Key: RANGER-4706 > URL: https://issues.apache.org/jira/browse/RANGER-4706 > Project: Ranger > Issue Type: Bug > Components: plugins >Reporter: suja s >Priority: Major > > STEPS TO REPRODUCE: > As user having admin role on Ranger side, execute "show principals > " command via hive beeline > CURRENT BEHAVIOUR: > Command fails with error stating 'User not authorized to perform this > operation' > If we add the user to property "ranger.plugin.service.admins" in repo config, > then the command execution is successful which means even if user is ranger > admin, user should be configured as service admin for the operation to be > successful. Filing jira to confirm if this is expected behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4706) Hive Show principals command not working for ranger admin user
suja s created RANGER-4706: -- Summary: Hive Show principals command not working for ranger admin user Key: RANGER-4706 URL: https://issues.apache.org/jira/browse/RANGER-4706 Project: Ranger Issue Type: Bug Components: plugins Reporter: suja s STEPS TO REPRODUCE: As user having admin role on Ranger side, execute "show principals " command via hive beeline CURRENT BEHAVIOUR: Command fails with error stating 'User not authorized to perform this operation' If we add the user to property "ranger.plugin.service.admins" in repo config, then the command execution is successful which means even if user is ranger admin, user should be configured as service admin for the operation to be successful. Filing jira to confirm if this is expected behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4705) Alter table concatenate command not authorised by ranger
suja s created RANGER-4705: -- Summary: Alter table concatenate command not authorised by ranger Key: RANGER-4705 URL: https://issues.apache.org/jira/browse/RANGER-4705 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Create a ranger hive policy for user u1 to have all access except ALTER on table t1 Create table t1 with partition and add data. As user u1, execute alter table concatenate command CURRENT BEHAVIOUR: Concatenate command is successful, authorization is not happening through ranger, No access audits available. Other alter commands are authorized by ranger -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4703) Show materialized views command not audited in ranger
suja s created RANGER-4703: -- Summary: Show materialized views command not audited in ranger Key: RANGER-4703 URL: https://issues.apache.org/jira/browse/RANGER-4703 Project: Ranger Issue Type: Bug Components: audit Reporter: suja s STEPS TO REPRODUCE: Create a ranger hive policy for user u1 to access table t1, view v1 and materialized view mv1. Create table t1 and add data. Create view v1 and materialized view mv1. Execute command 'show materialized views'. Inspect access audit logs on Ranger Admin UI CURRENT BEHAVIOUR: No access audit logs generated for command execution EXPECTED BEHAVIOUR: Access audits should be generated for command execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4704) Not able to perform materialized views rebuild if user is granted update access after initial deny of operation
suja s created RANGER-4704: -- Summary: Not able to perform materialized views rebuild if user is granted update access after initial deny of operation Key: RANGER-4704 URL: https://issues.apache.org/jira/browse/RANGER-4704 Project: Ranger Issue Type: Bug Components: plugins Reporter: suja s STEPS TO REPRODUCE: Create a ranger hive policy for user u1 to access table t1, view v1 and create permission on materialized view mv1. Create table t1 and add data. Create view v1 and materialized view mv1. Insert an additional record in t1. Execute rebuild command on materialized view. Access is denied as user is not having update permissions on materialized view. Update ranger policy to provide 'update' access for user on materialized view and wait for policy to be available on hive plugin side. Execute rebuild command. CURRENT BEHAVIOUR: Operation fails with error stating that "Another process is rebuilding the materialized view" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4702) Confirmation regarding RF/ColMask on materialized views
suja s created RANGER-4702: -- Summary: Confirmation regarding RF/ColMask on materialized views Key: RANGER-4702 URL: https://issues.apache.org/jira/browse/RANGER-4702 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Create a ranger hive policy for user u1 to access table t1, view v1 and materialized view mv1. Create table t1 and add data. Create view v1 and materialized view mv1. Add a column masking policy for one of the columns of table t1 Try select data from t1, v1 and mv1 CURRENT BEHAVIOUR: Select works for t1 and v1 and data is masked in results based on the enforced column mask policy. For materialized view, select is not allowed Error: Error while compiling statement: FAILED: SemanticException [Error 10288]: Querying directly materialized view contents is not supported since we detected db1.t1 used by materialized view has row masking/column filtering enabled (state=42000,code=10288) EXPECTED BEHAVIOUR: Need confirmation on expected behaviour for materialized view -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4690) Access Audits - Resource policy version used for mask policy leading to Error page
suja s created RANGER-4690: -- Summary: Access Audits - Resource policy version used for mask policy leading to Error page Key: RANGER-4690 URL: https://issues.apache.org/jira/browse/RANGER-4690 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s Create a ranger hive policy for user u1 to access table t1. Create table t1 and add data Edit the policy to have multiple versions. Polocy version is now 'y' Create a ranger hive masking policy for one of the columns of t1. Edit the policy to have multiple versions. Policy version is less than 'y' example, if resource policy version is 5, have masking policy version as 4. Try insert command on t1. It fails now as there is a masking policy. Inspect access audits on ranger admin UI. Click on policyid for the denied audit for insert CURRENT BEHAVIOUR: Access audits show version of resource policy for mask policy id, so querying for policy details leads to data not found error page Policy cache json file on plugin side has the right version, x_policy table has the right entries for corresponding masking policy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4688) Display query information for Show databases/schemas command on Ranger Admin UI
suja s created RANGER-4688: -- Summary: Display query information for Show databases/schemas command on Ranger Admin UI Key: RANGER-4688 URL: https://issues.apache.org/jira/browse/RANGER-4688 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Connect to hive beeline Execute command 'show databases' Execute command 'show schemas' Execute command 'show tables' CURRENT BEHAVIOUR: Query information is present for 'show tables' command execution and not for 'show databases' or 'show schemas' command EXPECTED BEHAVIOUR: Query information should be present for 'show databases' and 'show schemas' commands -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4523) Suggestion on improving logs from AtlasNotificationMapper
suja s created RANGER-4523:
--
Summary: Suggestion on improving logs from AtlasNotificationMapper
Key: RANGER-4523
URL: https://issues.apache.org/jira/browse/RANGER-4523
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: suja s
STEPS TO REPRODUCE:
Create hive db/table so that hive entities are created on atlas side
Create classifications
Create a tag policy and verify tag policy enforcement
Inspect tagsync logs
CURRENT BEHAVIOUR:
Since hive_process entity-type notifications are not handled by tagsync, there
is a WARN message indicating this.
There are lot of log messages related to this
{noformat}
2023-10-09 08:14:02,300 WARN
org.apache.ranger.tagsync.source.atlas.AtlasNotificationMapper: [Thread-19]:
Tag-sync is not enabled to handle notifications for Entity-type:[hive_process]
2023-10-09 08:14:02,300 WARN
org.apache.ranger.tagsync.source.atlas.AtlasNotificationMapper: [Thread-19]:
Dropped process entity notification for Atlas-Entity [{typeName=hive_process,
guid=41cffa4b-be0e-42ca-aa16-688e1b00526e, attributes={ name=qualifiedName,
value=rgrtestdb.rgrtblctas@cm:1696835704000 name=clusterName, value=cm
name=name, value=rgrtestdb.rgrtblctas@cm:1696835704000}]
{noformat}
Suggestion:
The logs related to dropping of notifications for hive_process can be logged as
DEBUG/INFO rather than WARN
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4521) All records not displayed on Admin Audits UI when filtered using session ID
suja s created RANGER-4521: -- Summary: All records not displayed on Admin Audits UI when filtered using session ID Key: RANGER-4521 URL: https://issues.apache.org/jira/browse/RANGER-4521 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s STEPS TO REPRODUCE: Login as keyadmin user to Ranger Admin UI. Add a ranger kms policy by doing a json import. Navigate to Admin Audits on UI Click on the session ID corresponding to policy import and select "Show Actions" so that audits related to specific sessionID are displayed CURRENT BEHAVIOUR: Some audit entries are missing when filtered using sessionID (Audots for import and export are shown, audit corresponding to policy create is missing) EXPECTED BEHAVIOUR: All audits corresponding to filtered sessionID should be displayed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4520) Both usersync/tagsync instances becoming active and syncing users/tags
suja s created RANGER-4520: -- Summary: Both usersync/tagsync instances becoming active and syncing users/tags Key: RANGER-4520 URL: https://issues.apache.org/jira/browse/RANGER-4520 Project: Ranger Issue Type: Bug Components: Ranger Reporter: suja s Both usersync/tagsync instances becoming active and syncing users/tags in the following scenario Scenario: Bring up 2 instances of UserSync so that one is active and other is passive Cluster has 3 zk instances, stop 2 zk servers so that there is no quorum Both usersync instances fail to establish Zk connection Start both zk servers Both usersync instances have transitioned to active and started performing usersync Same issue exists for tagsync also Test: Add user u1 to host1 Add user u2 to host2 Both users are synced and available on ranger admin side. Usersync audits show details of both users synced EXPECTED BEHAVIOUR: In case of usersync/tagsync running in HA mode, there should be only 1 instance active at any point of time CURRENT BEHAVIOUR: After zk goes down and is back functional, more than 1 usersync/tagsync instance becoming active -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4452) Audit action details not logged for some kerberos login session
suja s created RANGER-4452: -- Summary: Audit action details not logged for some kerberos login session Key: RANGER-4452 URL: https://issues.apache.org/jira/browse/RANGER-4452 Project: Ranger Issue Type: Bug Components: admin Reporter: suja s STEPS TO REPRODUCE: Login to Ranger Admin UI as admin user Navigate to Audits page Select "Login Sessions" tab Choose LoginType as "Kerberos" and Login Id as "kafka" in the search filters Large no of audit entries get listed. Click on any one session id Click on "Show actions" link The displayed page doesn't list any details CURRENT BEHAVIOUR: There are large no of sessions getting established only for kafka user loginid Audit action details not logged for Kafka kerberos login session EXPECTED BEHAVIOUR: Audit action details should be logged for Kafka kerberos login session -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4451) RANGER-4286 allows security-zone to exist without any services/resources assigned yet, so when the last service is removed from zone, the zone should not get deleted
suja s created RANGER-4451: -- Summary: RANGER-4286 allows security-zone to exist without any services/resources assigned yet, so when the last service is removed from zone, the zone should not get deleted Key: RANGER-4451 URL: https://issues.apache.org/jira/browse/RANGER-4451 Project: Ranger Issue Type: Improvement Components: admin Reporter: suja s STEPS TO REPRODUCE: Create a service (cm_test) Create a security zone z1 with cm_test service added z1 is created successfully Delete cm_test CURRENT BEHAVIOUR: Zone z1 also gets deleted EXPECTED BEHAVIOUR: Zone z1 should not be deleted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-3364) Access audits - Incorrect hive query displayed for show current roles command
suja s created RANGER-3364: -- Summary: Access audits - Incorrect hive query displayed for show current roles command Key: RANGER-3364 URL: https://issues.apache.org/jira/browse/RANGER-3364 Project: Ranger Issue Type: Bug Components: audit Reporter: suja s Execute "show current roles" command from a hive beeline session. Ranger access audits page shows the hive query as "show roles". "Show roles" and "Show current roles" are different commands on hive side -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-2619) Admin Audit Details not displayed for edit role
[ https://issues.apache.org/jira/browse/RANGER-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s updated RANGER-2619: --- Attachment: AdminAudits_EditRole.png > Admin Audit Details not displayed for edit role > --- > > Key: RANGER-2619 > URL: https://issues.apache.org/jira/browse/RANGER-2619 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: suja s >Priority: Major > Attachments: AdminAudits_EditRole.png > > > When an existing role is edited by adding a new group or role, the details > are not displayed in the admin access details popup -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-2619) Admin Audit Details not displayed for edit role
suja s created RANGER-2619: -- Summary: Admin Audit Details not displayed for edit role Key: RANGER-2619 URL: https://issues.apache.org/jira/browse/RANGER-2619 Project: Ranger Issue Type: Bug Components: admin Reporter: suja s When an existing role is edited by adding a new group or role, the details are not displayed in the admin access details popup -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-2618) Restrict rolename change when a policy with that role exist
suja s created RANGER-2618: -- Summary: Restrict rolename change when a policy with that role exist Key: RANGER-2618 URL: https://issues.apache.org/jira/browse/RANGER-2618 Project: Ranger Issue Type: Bug Components: admin Reporter: suja s When we try to delete a role associated with a ranger policy, the operation is not allowed. Likewise, role edit for rolename change also should be restricted. Reason: Rolename edit is allowed and the ranger policy still exists with old rolename reference. Policy enforcement happens as per old policy. Rolename change is not taken into consideration during policy download. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (RANGER-2617) Provide descriptive error message when role delete not allowed
suja s created RANGER-2617:
--
Summary: Provide descriptive error message when role delete not
allowed
Key: RANGER-2617
URL: https://issues.apache.org/jira/browse/RANGER-2617
Project: Ranger
Issue Type: Bug
Components: admin
Reporter: suja s
Scenario:
Create a role r1
Create a ranger policy for role r1
Try to delete role
Role delete is not allowed as a policy exists with the specified role
Response:
{noformat}
{"statusCode":1,"msgDesc":"XXRole can't be
deleted","messageList":[{"name":"OPER_NOT_ALLOWED_FOR_STATE","rbKey":"xa.error.oper_not_allowed_for_state","message":"Operation
not allowed in current state","objectId":9}]}
{noformat}
Expected:
Descriptive message with details on why the operation is not allowed
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (RANGER-2474) Policy version and details in access audits wrong when deny condition added to policy
suja s created RANGER-2474: -- Summary: Policy version and details in access audits wrong when deny condition added to policy Key: RANGER-2474 URL: https://issues.apache.org/jira/browse/RANGER-2474 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 2.0.0 Reporter: suja s Scenario: Create a ranger hive policy for a test table for select access - version1 Perform select - operation successful (done for impala) Validate access audits - policy version is 1, clicking on policyid shows details of policy at version1 Edit the policy to include and an additional policy item under allow or a new condition under allow exception or deny exception (not under deny) Perform operation Validate access audits - policy version is 2, clicking on policyid shows details of policy at version2 Edit the policy to include a deny condition Perform operation Validate access audits - policy version is 1, clicking on policyid shows details of policy at version1 though enforcement happens as per policy version3 Note - Versioning is back to normal when deny condition is removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2383) Incorrect response when trying to delete user attached to a security zone
[
https://issues.apache.org/jira/browse/RANGER-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
suja s updated RANGER-2383:
---
Fix Version/s: master
> Incorrect response when trying to delete user attached to a security zone
> -
>
> Key: RANGER-2383
> URL: https://issues.apache.org/jira/browse/RANGER-2383
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: master
>Reporter: suja s
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: master
>
>
> Scenario:
> Create a test user (user role is USER)
> Create a security zone with the above user as admin user
> Try to delete the user
> Delete operation fails, but there is no reason for the failure, api response
> gives a 404 error
> The same occurs if that user is tagged as auditor for security zone
> The scenario is applicable for group also
> Expected: If user delete is not allowed, proper response indicating the
> reason for failure should be displayed
> Note: This behaviour is different from user assigned as delegated admin for a
> policy, even if a user is delegated admin for a policy, user delete is
> successful
> {noformat}
> Request URL:
> http://:/service/xusers/secure/users/id/?forceDelete=true
> Request Method: DELETE
> Status Code: 404 Not Found
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RANGER-2383) Incorrect response when trying to delete user attached to a security zone
suja s created RANGER-2383:
--
Summary: Incorrect response when trying to delete user attached to
a security zone
Key: RANGER-2383
URL: https://issues.apache.org/jira/browse/RANGER-2383
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: suja s
Scenario:
Create a test user (user role is USER)
Create a security zone with the above user as admin user
Try to delete the user
Delete operation fails, but there is no reason for the failure, api response
gives a 404 error
The same occurs if that user is tagged as auditor for security zone
The scenario is applicable for group also
Expected: If user delete is not allowed, proper response indicating the reason
for failure should be displayed
Note: This behaviour is different from user assigned as delegated admin for a
policy, even if a user is delegated admin for a policy, user delete is
successful
{noformat}
Request URL:
http://:/service/xusers/secure/users/id/?forceDelete=true
Request Method: DELETE
Status Code: 404 Not Found
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-2383) Incorrect response when trying to delete user attached to a security zone
[
https://issues.apache.org/jira/browse/RANGER-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
suja s updated RANGER-2383:
---
Affects Version/s: master
> Incorrect response when trying to delete user attached to a security zone
> -
>
> Key: RANGER-2383
> URL: https://issues.apache.org/jira/browse/RANGER-2383
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: master
>Reporter: suja s
>Priority: Major
>
> Scenario:
> Create a test user (user role is USER)
> Create a security zone with the above user as admin user
> Try to delete the user
> Delete operation fails, but there is no reason for the failure, api response
> gives a 404 error
> The same occurs if that user is tagged as auditor for security zone
> The scenario is applicable for group also
> Expected: If user delete is not allowed, proper response indicating the
> reason for failure should be displayed
> Note: This behaviour is different from user assigned as delegated admin for a
> policy, even if a user is delegated admin for a policy, user delete is
> successful
> {noformat}
> Request URL:
> http://:/service/xusers/secure/users/id/?forceDelete=true
> Request Method: DELETE
> Status Code: 404 Not Found
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RANGER-2229) Perform graceful terminate with retries before doing forceful kill for usersync and tagsync
[
https://issues.apache.org/jira/browse/RANGER-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
suja s resolved RANGER-2229.
Resolution: Fixed
> Perform graceful terminate with retries before doing forceful kill for
> usersync and tagsync
> ---
>
> Key: RANGER-2229
> URL: https://issues.apache.org/jira/browse/RANGER-2229
> Project: Ranger
> Issue Type: Bug
> Components: tagsync, usersync
>Affects Versions: 1.1.0
>Reporter: suja s
>Assignee: bhavik patel
>Priority: Major
> Attachments: RANGER-2229-01.patch, RANGER-2229.patch
>
>
> In ranger usersync and tagsync scripts, stop of the process is done
> forcefully using kill -9.
> Suggestion is to do a graceful shutdown with retries and do a force kill only
> if graceful shutdown is not successful.
> Stop section from ranger-tagsync-services.sh and ranger-tusersync-services.sh
> {noformat}
> lif [ "${action}" == "STOP" ]; then
> WAIT_TIME_FOR_SHUTDOWN=2
> NR_ITER_FOR_SHUTDOWN_CHECK=15
> if [ -f "$pidf" ] ; then
> pid=`cat $pidf` > /dev/null 2>&1
> echo "Found Apache Ranger TagSync Service with pid $pid, Stopping..."
> kill -9 $pid > /dev/null 2>&1
> sleep 1 #Give kill -9 sometime to "kill"
> if ps -p $pid > /dev/null; then
> echo "Wow, even kill -9 failed, giving up! Sorry.."
> else
> rm -f $pidf
> echo "Apache Ranger Tagsync Service pid = ${pid} has been stopped."
> fi
> else
> echo "Ranger Tagsync Service not running"
> fi
> exit;
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (RANGER-2229) Perform graceful terminate with retries before doing forceful kill for usersync and tagsync
[
https://issues.apache.org/jira/browse/RANGER-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
suja s reopened RANGER-2229:
Currently ranger-tagsync-services.sh/ranger-usersync-services.sh are not
idempotent regarding the stop command with respect to ranger-admin. Reopening
the issue to address that.
> Perform graceful terminate with retries before doing forceful kill for
> usersync and tagsync
> ---
>
> Key: RANGER-2229
> URL: https://issues.apache.org/jira/browse/RANGER-2229
> Project: Ranger
> Issue Type: Bug
> Components: tagsync, usersync
>Affects Versions: 1.1.0
>Reporter: suja s
>Assignee: bhavik patel
>Priority: Major
> Attachments: RANGER-2229.patch
>
>
> In ranger usersync and tagsync scripts, stop of the process is done
> forcefully using kill -9.
> Suggestion is to do a graceful shutdown with retries and do a force kill only
> if graceful shutdown is not successful.
> Stop section from ranger-tagsync-services.sh and ranger-tusersync-services.sh
> {noformat}
> lif [ "${action}" == "STOP" ]; then
> WAIT_TIME_FOR_SHUTDOWN=2
> NR_ITER_FOR_SHUTDOWN_CHECK=15
> if [ -f "$pidf" ] ; then
> pid=`cat $pidf` > /dev/null 2>&1
> echo "Found Apache Ranger TagSync Service with pid $pid, Stopping..."
> kill -9 $pid > /dev/null 2>&1
> sleep 1 #Give kill -9 sometime to "kill"
> if ps -p $pid > /dev/null; then
> echo "Wow, even kill -9 failed, giving up! Sorry.."
> else
> rm -f $pidf
> echo "Apache Ranger Tagsync Service pid = ${pid} has been stopped."
> fi
> else
> echo "Ranger Tagsync Service not running"
> fi
> exit;
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RANGER-2229) Perform graceful terminate with retries before doing forceful kill for usersync and tagsync
suja s created RANGER-2229:
--
Summary: Perform graceful terminate with retries before doing
forceful kill for usersync and tagsync
Key: RANGER-2229
URL: https://issues.apache.org/jira/browse/RANGER-2229
Project: Ranger
Issue Type: Bug
Components: tagsync, usersync
Affects Versions: 1.1.0
Reporter: suja s
In ranger usersync and tagsync scripts, stop of the process is done forcefully
using kill -9.
Suggestion is to do a graceful shutdown with retries and do a force kill only
if graceful shutdown is not successful.
Stop section from ranger-tagsync-services.sh and ranger-tusersync-services.sh
{noformat}
lif [ "${action}" == "STOP" ]; then
WAIT_TIME_FOR_SHUTDOWN=2
NR_ITER_FOR_SHUTDOWN_CHECK=15
if [ -f "$pidf" ] ; then
pid=`cat $pidf` > /dev/null 2>&1
echo "Found Apache Ranger TagSync Service with pid $pid, Stopping..."
kill -9 $pid > /dev/null 2>&1
sleep 1 #Give kill -9 sometime to "kill"
if ps -p $pid > /dev/null; then
echo "Wow, even kill -9 failed, giving up! Sorry.."
else
rm -f $pidf
echo "Apache Ranger Tagsync Service pid = ${pid} has been stopped."
fi
else
echo "Ranger Tagsync Service not running"
fi
exit;
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RANGER-1711) ValidateConfig always returns the return code as 200 irrespective of whether test connection is successful or not
[ https://issues.apache.org/jira/browse/RANGER-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s resolved RANGER-1711. Resolution: Not A Problem > ValidateConfig always returns the return code as 200 irrespective of whether > test connection is successful or not > - > > Key: RANGER-1711 > URL: https://issues.apache.org/jira/browse/RANGER-1711 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 0.7.1 >Reporter: suja s > Fix For: 0.7.2 > > > ValidateConfig always returns the return code as 200 irrespective of whether > test connection is successful or not -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RANGER-1711) ValidateConfig always returns the return code as 200 irrespective of whether test connection is successful or not
suja s created RANGER-1711: -- Summary: ValidateConfig always returns the return code as 200 irrespective of whether test connection is successful or not Key: RANGER-1711 URL: https://issues.apache.org/jira/browse/RANGER-1711 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 0.7.1 Reporter: suja s Fix For: 0.7.2 ValidateConfig always returns the return code as 200 irrespective of whether test connection is successful or not -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (RANGER-1675) Policy conditions not enabled by default for Hive policies
[ https://issues.apache.org/jira/browse/RANGER-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s resolved RANGER-1675. Resolution: Not A Bug > Policy conditions not enabled by default for Hive policies > -- > > Key: RANGER-1675 > URL: https://issues.apache.org/jira/browse/RANGER-1675 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 0.7.2 >Reporter: suja s > > Policy conditions (like expiry_date) are not visible by default on Ranger UI > for hive policy creation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RANGER-1675) Policy conditions not enabled by default for Hive policies
[ https://issues.apache.org/jira/browse/RANGER-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suja s updated RANGER-1675: --- Affects Version/s: (was: 0.7.1) 0.7.2 > Policy conditions not enabled by default for Hive policies > -- > > Key: RANGER-1675 > URL: https://issues.apache.org/jira/browse/RANGER-1675 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 0.7.2 >Reporter: suja s > > Policy conditions (like expiry_date) are not visible by default on Ranger UI > for hive policy creation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RANGER-1675) Policy conditions not enabled by default for Hive policies
suja s created RANGER-1675: -- Summary: Policy conditions not enabled by default for Hive policies Key: RANGER-1675 URL: https://issues.apache.org/jira/browse/RANGER-1675 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 0.7.1 Reporter: suja s Policy conditions (like expiry_date) are not visible by default on Ranger UI for hive policy creation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
