[jira] [Updated] (RANGER-4901) [Ranger React UI] Admin audits for "Import Delete" operation type do not display service name field
[ https://issues.apache.org/jira/browse/RANGER-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4901: - Reporter: Abhishek (was: Dhaval Rajpara) > [Ranger React UI] Admin audits for "Import Delete" operation type do not > display service name field > --- > > Key: RANGER-4901 > URL: https://issues.apache.org/jira/browse/RANGER-4901 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhishek >Assignee: Dhaval Rajpara >Priority: Major > > In Ranger React UI, in admin audits, the "Service name" field is missing for > the audits of operation type "Import Delete". > In Backbone UI, for the same admin audits, the "Service name" field is > present. > *Steps to reproduce :-* > 1. Login to Ranger admin UI > 2. Export the policies for any service, for e.g, cm_hdfs > 3. Import the policies from the json file which was obtained in step 2. While > importing the policies, check the override option. > 4. Navigate to the admin audits page, and in the admin audits page, audits > will be generated for "Import Delete" action. > 5. Click on any audit with the "Import Delete" action, in the popup, the > details are present for the policy which is deleted during the policy import > operation. > In the popup, the service name field is missing > 6. Now switch to Backbone UI, navigate to admin audits page, and click on the > same audit. In the popup, the service name field is present for the audit > *Attachments :-* > 1. Screenshot 1 : Admin audit for "Import Delete" operation in Backbone UI, > displaying the service name field > 2. Screenshot 2 : Admin audit for "Import Delete" operation in React UI, > which does not contain the service name field -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4823) Incorrect processing of downloaded policies in plugin when policy-deltas are enabled
[ https://issues.apache.org/jira/browse/RANGER-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4823: - Fix Version/s: 3.0.0 > Incorrect processing of downloaded policies in plugin when policy-deltas are > enabled > > > Key: RANGER-4823 > URL: https://issues.apache.org/jira/browse/RANGER-4823 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > When policy deltas are enabled, and there is no material change in policy-set > after previous policy download processed by Ranger admin, the ServicePolicies > object downloaded contains null value instead of an empty list for > policyDeltas attribute because of change made to the annotations by > RANGER-3948. As the plugin considers empty-list value differently than null > value, the policy-engine built by the plugin does not correctly reflect the > existing policy-set, and leads to incorrect authorization result. > > A material change to policy-set indicates that there is at least one policy > added/deleted/updated to previous policy-set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4770) Make RangerAccessRequestImpl backward compatible after RANGER-2763
[ https://issues.apache.org/jira/browse/RANGER-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-4770: Assignee: (was: Peter Turcsanyi) > Make RangerAccessRequestImpl backward compatible after RANGER-2763 > -- > > Key: RANGER-4770 > URL: https://issues.apache.org/jira/browse/RANGER-4770 > Project: Ranger > Issue Type: Task > Components: admin >Reporter: Fang-Yu Rao >Priority: Major > > We changed the signature of the class RangerAccessRequestImpl in RANGER-2763 > by adding an additional input argument 'userRoles'. > {code} > public RangerAccessRequestImpl(RangerAccessResource resource, String > accessType, String user, Set userGroups, Set userRoles) { > ... > {code} > > It would be great to make this constructor backward compatible because other > Apache components, e.g., Apache Impala, is currently using the old > constructor. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4770) Make RangerAccessRequestImpl backward compatible after RANGER-2763
[ https://issues.apache.org/jira/browse/RANGER-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-4770: Assignee: Peter Turcsanyi > Make RangerAccessRequestImpl backward compatible after RANGER-2763 > -- > > Key: RANGER-4770 > URL: https://issues.apache.org/jira/browse/RANGER-4770 > Project: Ranger > Issue Type: Task > Components: admin >Reporter: Fang-Yu Rao >Assignee: Peter Turcsanyi >Priority: Major > > We changed the signature of the class RangerAccessRequestImpl in RANGER-2763 > by adding an additional input argument 'userRoles'. > {code} > public RangerAccessRequestImpl(RangerAccessResource resource, String > accessType, String user, Set userGroups, Set userRoles) { > ... > {code} > > It would be great to make this constructor backward compatible because other > Apache components, e.g., Apache Impala, is currently using the old > constructor. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4722) HDFS authorization logic for directory hierarchy rooted at "/" is incorrect
[ https://issues.apache.org/jira/browse/RANGER-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4722: - Fix Version/s: 3.0.0 > HDFS authorization logic for directory hierarchy rooted at "/" is incorrect > --- > > Key: RANGER-4722 > URL: https://issues.apache.org/jira/browse/RANGER-4722 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > Ranger authorization logic for the HDFS commands that require authorization > of the entire directory hierarchy rooted at the specified directory argument > is incorrect as it does not correctly compute the sub-directory paths. The > paths of sub-directories that need to be authorized incorrectly contain an > extra '/' character, which leads to incorrect authorization result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4639) Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy
[ https://issues.apache.org/jira/browse/RANGER-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4639: - Fix Version/s: 3.0.0 > Provide an option to bypass evaluation of chained plugin if the parent plugin > has applicable policy > --- > > Key: RANGER-4639 > URL: https://issues.apache.org/jira/browse/RANGER-4639 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > When a chained plugin is configured, for every access request processed by > the parent plugin is also processed by chained plugin. It may be appropriate, > in some cases, under a configuration option, to bypass the evaluation of > chained plugin when an applicable policy is found by the parent plugin. > > This is controlled by a configuration parameter: > ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined > with a default value of false. If it is set to true, then the chanined plugin > evaluation will be bypassed - if the base-plugin found applicable policy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4585) Support multiple columns policy creation in ranger for Grant / Revoke request
[ https://issues.apache.org/jira/browse/RANGER-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4585: - Fix Version/s: 3.0.0 > Support multiple columns policy creation in ranger for Grant / Revoke request > - > > Key: RANGER-4585 > URL: https://issues.apache.org/jira/browse/RANGER-4585 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4585-Support-multiple-columns-policy-creation.patch > > > Support multiple columns policy creation in ranger for Grant / Revoke request > When request like "grant select ( col1, col2, col3, col4, col5, col6, col7, > col8, col9, col10) on table demo.data5 to role testrole_09289898" is done in > Impala or Hive ranger doesn't create those columns in a single policy. In > Impala case it create one grant for each of the column. In Hive it creates a > "*" column policy. This has to be modified to support creation of single > policy for grant with all the columns added.Same case for Revoke, need to > support update of the policies correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4495) Upgrade netty to 4.1.100-final
[ https://issues.apache.org/jira/browse/RANGER-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4495: - Summary: Upgrade netty to 4.1.100-final (was: CLONE - Upgrade netty to 4.1.100-final) > Upgrade netty to 4.1.100-final > -- > > Key: RANGER-4495 > URL: https://issues.apache.org/jira/browse/RANGER-4495 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Pradeep Agrawal >Assignee: Pradeep Agrawal >Priority: Major > Fix For: 3.0.0 > > > Upgrade netty to 4.1.100-final or higher -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4467) User Agent info not logged under "Login sessions" when login fails
[ https://issues.apache.org/jira/browse/RANGER-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4467: - Reporter: suja s (was: Rakesh Gupta) > User Agent info not logged under "Login sessions" when login fails > -- > > Key: RANGER-4467 > URL: https://issues.apache.org/jira/browse/RANGER-4467 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Assignee: Rakesh Gupta >Priority: Major > Attachments: > 0001-RANGER-4467-User-Agent-info-not-logged-under-Login-s.patch > > > STEPS TO REPRODUCE: > Provide wrong uname or password on Ranger admin UI so that login fails > Verify login sessions under Audits page > CURRENT BEHAVIOUR: > User Agent info is missing when login fails > EXPECTED BEHAVIOUR: > User Agent info should be displayed > IMPACT: > User Agent info missing when login fails. Its good to display this detail as > it helps in knowing how the login was tried in case of failed login attempts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4317) [Ranger UI] Error message displayed when resource lookup fails is not formatted properly
[ https://issues.apache.org/jira/browse/RANGER-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4317: - Reporter: Abhishek (was: Dhaval Rajpara) > [Ranger UI] Error message displayed when resource lookup fails is not > formatted properly > > > Key: RANGER-4317 > URL: https://issues.apache.org/jira/browse/RANGER-4317 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhishek >Assignee: Brijesh Bhalala >Priority: Major > Labels: ranger-react > Fix For: 3.0.0 > > Attachments: 0001-RANGER-4317.patch, image (4).png > > > When a resource lookup fails on the new UI due to some config issue, > the error message is not displayed properly > But on backbone JS, it is displayed properly. > The error message on react js must be formatted properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3554) [Intermittent] API call to fetch the list of policies for a particular service repo returns a deleted policy in the response
[ https://issues.apache.org/jira/browse/RANGER-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3554: - Reporter: Abhishek (was: Abhay Kulkarni) > [Intermittent] API call to fetch the list of policies for a particular > service repo returns a deleted policy in the response > > > Key: RANGER-3554 > URL: https://issues.apache.org/jira/browse/RANGER-3554 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhishek >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > Multiple tests are executed during the test run, and the flow of the tests is > as follows:- > # A set of policies needed for the test are created for a Ranger service. > # Tests are run. > # All existing policies in the Ranger service are deleted by fetching all > policies in the service, and deleting them one-by-one. Each delete call are > successful. > # All policies in the Ranger service are fetched to ensure that no policies > are remaining in the Ranger service. > It is expected that in step 4, no policies are returned. However, > intermittently, step 4 returns policy that is deleted in step 3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3502) Make GET zone APIs accessible to authorized users only
[ https://issues.apache.org/jira/browse/RANGER-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3502: - Reporter: Abhishek (was: Kishor Gollapalliwar) > Make GET zone APIs accessible to authorized users only > -- > > Key: RANGER-3502 > URL: https://issues.apache.org/jira/browse/RANGER-3502 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhishek >Assignee: Kishor Gollapalliwar >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > Currently get > [zones|https://ranger.apache.org/apidocs/resource_SecurityZoneREST.html#resource_SecurityZoneREST_getAllZones_GET] > API returns all zones even for users who are not authorized to zone modules. > Restrict this API to only users who are authorized to zone module. > Steps to reproduce: > # Create a internal user name, test_user1 > # Remove the permission on Security Zone module for a user > # Login as test_user1 user to Ranger Admin, user should not be able to see > Security Zone tab > # Access the API using curl > {code:java} > curl -ikv -u test_user1:pass@123 -X GET -H "Accept:application/json" -H > "Content-Type:application/json" > "https://:6182/service/zones/zones" > {code} > {code:java} > curl -ikv -u test_user1:pass@123 -X GET -H "Accept:application/json" -H > "Content-Type:application/json" > "https://:6182/service/zones/zones/{ID}" > {code} > {code:java} > curl -ikv -u test_user1:pass@123 -X GET -H "Accept:application/json" -H > "Content-Type:application/json" > "https://:6182/service/zones/zones/name/{ZONE_NAME}" > {code} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3995) Policy update request fails if isDenyAllElse flag is set true in request json when using "/policy/apply" API
[ https://issues.apache.org/jira/browse/RANGER-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3995: - Reporter: Abhishek (was: Pradeep Agrawal) > Policy update request fails if isDenyAllElse flag is set true in request json > when using "/policy/apply" API > > > Key: RANGER-3995 > URL: https://issues.apache.org/jira/browse/RANGER-3995 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Abhishek >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > An issue was found with respect to "/policy/apply" API when the policy json > contains denyAllElse flag set true. > When a request is made to "/service/public/v2/api/policy/apply" using a > policy json where denyAllElse flag is set to true, > the policy is created successfully the first time. > But if a request is made again using the same policy json, it gives the > following error. > {code:java} > { > "statusCode": 1, > "msgDesc": "(0) Validation failure: error code[3049], reason[Deny or > deny-exceptions are not supported if policy has isDenyAllElse flag set to > true], field[policy items], subfield[null], type[] " > } {code} > Steps to reproduce :- > 1. Make a POST request to the below mentioned API endpoint, using a policy > json where isDenyAllElse flag is set true > /service/public/v2/api/policy/apply > 2. Fetch the policy using the newly created policy id, and try to make a POST > request to "/policy/apply" using the policy json obtained from the GET > request. The request results in an error -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3325) Roles information not present in the Excel and CSV files which are downloaded from Reports page
[ https://issues.apache.org/jira/browse/RANGER-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3325: - Reporter: Abhishek (was: Pradeep Agrawal) > Roles information not present in the Excel and CSV files which are downloaded > from Reports page > --- > > Key: RANGER-3325 > URL: https://issues.apache.org/jira/browse/RANGER-3325 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.2.0 >Reporter: Abhishek >Assignee: Pradeep Agrawal >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3325-Roles-information-not-present-in-the-Exc.patch > > > h4. Problem Statement: > When exporting the policies from the Reports page in Excel and CSV format, > the information about the roles in the policy is not present. > The roles information for a particular policy is visible when the policy > information > is exported in JSON format. > *Steps to reproduce:* > 1. Create a role > 2. Create a policy on that role > 3. On the reports page, export the policies information > in all the three available formats ( Excel, CSV, JSON). > 4. When the files are inspected, the roles information in the policy > is present only in the JSON file. Not in the Excel and CSV files. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3336) All policies are exported, when searching reports using roles
[ https://issues.apache.org/jira/browse/RANGER-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3336: - Reporter: Abhishek (was: Nitin Galave) > All policies are exported, when searching reports using roles > - > > Key: RANGER-3336 > URL: https://issues.apache.org/jira/browse/RANGER-3336 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhishek >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3336.patch > > > On the Reports page, when policies are searched using Role name, > and then exported, all the policies are listed in the downloaded file even if > only > one policy is shown in the search result. > Steps to reproduce : > 1. Create a policy on any role > 2. On the Reports page, search for policies using only the role name. > 3. Export the policies. > 4. In the downloaded file, all policies available in Ranger will be listed > even if the search results had one or two policies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4036) Hive Policy is not hounered for Drop non-existing database and non-existing table via unauthorized user
[ https://issues.apache.org/jira/browse/RANGER-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755054#comment-17755054 ] Velmurugan Periasamy commented on RANGER-4036: -- CC [~rmani] / [~mehul] > Hive Policy is not hounered for Drop non-existing database and non-existing > table via unauthorized user > > > Key: RANGER-4036 > URL: https://issues.apache.org/jira/browse/RANGER-4036 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Anupam Rai >Priority: Major > > Behaviour of Drop non-existing database and non-existing table for > unauthorized user is not proper. > Steps to reproduce : > 1. Create a policy for User1 having only select acess of database : test1 , > Table : testtable2, Column : * > 2. Run below command on non-existing database > {code:java} > DROP DATABASE IF EXISTS xyzwer; {code} > 3. Result > {code:java} > INFO : Compiling command(queryId=hive_***): DROP DATABASE IF EXISTS > xyzwer > DEBUG : Encoding valid txns info 167872:::167871 txnid:167872 > INFO : Semantic Analysis Completed (retrial = false) > INFO : Created Hive schema: Schema(fieldSchemas:null, properties:null) > INFO : Completed compiling command(queryId=***-9890-4f78-8d7d-9c75fb7c636d); > Time taken: 0.16 seconds > INFO : Executing > command(queryId=hive_20230105061438_e176728f-9890-4f78-8d7d-9c75fb7c636d): > DROP DATABASE IF EXISTS xyzwer > INFO : Completed executing command(queryId=***-9890-); Time taken: 0.009 > seconds > INFO : OK > DEBUG : Shutting down query DROP DATABASE IF EXISTS xyzwer > No rows affected (0.247 seconds) > 0: jdbc:hive2://quasar-**-1.{code} > 4. Run below command for non-existing table > {code:java} > DROP TABLE IF EXISTS . {code} > 5. Result > {code:java} > INFO : Semantic Analysis Completed (retrial = false) > INFO : Created Hive schema: Schema(fieldSchemas:null, properties:null) > INFO : Completed compiling > command(queryId=-aeed-4e60-83a1-2cc3d875c164); Time taken: 0.939 seconds > INFO : Executing command(queryId=***-aeed-4e60-83a1-2cc3d875c164): DROP > TABLE IF EXISTS . > INFO : Starting task [Stage-0:DDL] in serial mode > DEBUG : Task getting executed using mapred tag : > hive_20230105064408_d4b3da87-aeed-4e60-83a1-2cc3d875c164,userid=*** > INFO : Completed executing command(queryId=hive_); Time taken: 0.049 > seconds > INFO : OK > DEBUG : Shutting down query DROP {code} > Actual : Result shows non-existing Table & database commands are getting > executed for unauthorised user > Expected : Like behaviour in should be like result : > {code:java} > 0: jdbc:hive://l> DROP DATABASE IF EXISTS xyzwer; > Error: Error while compiling statement: FAILED: HiveAccessControlException > Permission denied: user [user] does not have [DROP] privilege on [xyzwer] > (state=42000,code=4) {code} > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4255) Introduce option in Ranger to control retention period of x_auth_sess table data
[ https://issues.apache.org/jira/browse/RANGER-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4255: - Issue Type: New Feature (was: Bug) > Introduce option in Ranger to control retention period of x_auth_sess table > data > > > Key: RANGER-4255 > URL: https://issues.apache.org/jira/browse/RANGER-4255 > Project: Ranger > Issue Type: New Feature > Components: Ranger >Reporter: Pradeep Agrawal >Assignee: Pradeep Agrawal >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4129) ArrayIndexOutOfBounds exception may be thrown while processing events
[ https://issues.apache.org/jira/browse/RANGER-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-4129: - Fix Version/s: 3.0.0 > ArrayIndexOutOfBounds exception may be thrown while processing events > - > > Key: RANGER-4129 > URL: https://issues.apache.org/jira/browse/RANGER-4129 > Project: Ranger > Issue Type: Bug > Components: tagsync >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > If AtlasTagSource.buildAndUploadServiceTags() is called with empty > AtlasTagSource.atlasEntityWithTags list, then an ArrayIndexOutOfBounds > exception is thrown when AtlasTagSource.messages list is read. This may > happen when the first notification processed by tagsync process is of type > ENTITY_DELETE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3756) ranger SQL-transaction can not work with GTID-enabled mysql server
[ https://issues.apache.org/jira/browse/RANGER-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626777#comment-17626777 ] Velmurugan Periasamy commented on RANGER-3756: -- CC [~pradeepagrawal8184] / [~abhayk] > ranger SQL-transaction can not work with GTID-enabled mysql server > -- > > Key: RANGER-3756 > URL: https://issues.apache.org/jira/browse/RANGER-3756 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: kirby zhou >Priority: Critical > > A lot of cloud mysql service provider enable GTID_MODE by default. > Such as TencentCloud, AliCloud, HuaWeiCloud. > But ranger is not compatible with GTID_MODE. > {code:java} > 2022-05-11 07:19:12,533 [http-nio-6080-exec-3] INFO > n.s.l.Slf4jSpyLogDelegator (Slf4jSpyLogDelegator.java:226) CREATE TEMPORARY > TABLE IF NOT EXISTS TL_x_rms_resource_mapping (id BIGINT NOT NULL, > change_timestamp > DATETIME, hl_resource_id BIGINT, ll_resource_id BIGINT, PRIMARY KEY (id)) > 2022-05-11 07:19:12,543 [http-nio-6080-exec-3] ERROR > n.s.l.Slf4jSpyLogDelegator (Slf4jSpyLogDelegator.java:111) 1. > PreparedStatement.executeUpdate() CREATE TEMPORARY TABLE IF NOT EXISTS > TL_x_rms_resource_mapping (id BIGINT NOT NULL, change_timestamp > DATETIME, hl_resource_id BIGINT, ll_resource_id BIGINT, PRIMARY KEY (id)) > java.sql.SQLException: Statement violates GTID consistency: CREATE TEMPORARY > TABLE and DROP TEMPORARY TABLE can only be executed outside transactional > context. These statements are also not allowed in a function or trigger > because functions and triggers are also considered to be multi-statement > transactions. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:998) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) > ... > at > org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:890) > at > org.apache.ranger.db.XXRMSServiceResourceDao.purge(XXRMSServiceResourceDao.java:248) > at > org.apache.ranger.biz.ServiceDBStore.deleteService(ServiceDBStore.java:1809) > Error! Exception [EclipseLink-4002] (Eclipse Persistence Services - > 2.5.2.v20140319-9ad6abd): > org.eclipse.persistence.exceptions.DatabaseException Internal Exception: > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table > 'ranger.tl_x_rms_resource_mapping' doesn't exist Error Code: 1146 Call: > INSERT INTO TL_x_rms_resource_mapping (id) SELECT t0.id FROM > x_rms_resource_mapping t0 WHERE (t0.hl_resource_id IN (SELECT t1.id FROM > x_rms_service_resource t1 WHERE (t1.service_id = ?)) OR t0.ll_resource_id IN > (SELECT t2.id FROM x_rms_service_resource t2 WHERE (t2.service_id = ?))) bind > => [2 parameters bound] Query: > DeleteAllQuery(name="XXRMSResourceMapping.deleteByServiceId" > referenceClass=XXRMSResourceMapping sql="DELETE FROM > TL_x_rms_resource_mapping") > {code} > > Because CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed > outside transactional context. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3754) Chained plugins access evaluation result is not considered in some cases
[ https://issues.apache.org/jira/browse/RANGER-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3754: - Fix Version/s: 3.0.0 > Chained plugins access evaluation result is not considered in some cases > > > Key: RANGER-3754 > URL: https://issues.apache.org/jira/browse/RANGER-3754 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > If the plugins are chained, the result of an access request combines the > access result of the main plugin with the result reported by the plugin > chained to the main plugin. In some cases (where fallback to native > authorizer is not enabled for the main plugin), the result of the chained > plugin's access result is not used if the chained plugin's policy that > evaluated the access is of same or lower priority. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3928) Refactor security-admin DAOs to allow non-relational data stores
[ https://issues.apache.org/jira/browse/RANGER-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608334#comment-17608334 ] Velmurugan Periasamy commented on RANGER-3928: -- [~deniswsrosa] - Thanks for your interest in contributing to Ranger. I have added you as a contributor. You can assign the JIRAs to yourself and provide contributions. Welcome to Ranger community. > Refactor security-admin DAOs to allow non-relational data stores > > > Key: RANGER-3928 > URL: https://issues.apache.org/jira/browse/RANGER-3928 > Project: Ranger > Issue Type: Improvement > Components: admin >Reporter: DENIS ROSA >Priority: Major > > Currently, the DAOs at the Security-admin module (org.apache.ranger.db > package) make it hard to add support for non-relational databases. We could > make the DAOs as interfaces and move the current code to an implementation > class instead. > This allows me to add custom DAO implementations for different databases > without braking the current implementation. > > {*}NOTE{*}: I would like to work on this issue if some of the committers are > willing to review and accept the PR. (I guess I can have something ready in > ~a month) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3790) Ranger tagsync module should not depend on kafka server
[ https://issues.apache.org/jira/browse/RANGER-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556914#comment-17556914 ] Velmurugan Periasamy commented on RANGER-3790: -- [~pmarton] - thanks for your interest in contributing to Ranger. Welcome to Ranger community. I have added you as contributor. You can assign jiras to yourself now. Thanks. > Ranger tagsync module should not depend on kafka server > --- > > Key: RANGER-3790 > URL: https://issues.apache.org/jira/browse/RANGER-3790 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0 >Reporter: Patrik Márton >Priority: Major > > This is a follow-up of RANGER-2426. > Kafka Core dependency has already been removed from tagsync as part of the > mentioned ticket, but since the _distro/src/main/assembly/tagsync.xml_ > contains this dependency, it is included in the distribution. > [https://github.com/apache/ranger/blob/master/distro/src/main/assembly/tagsync.xml#L56] > > The goal is to remove this from the assembly. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (RANGER-3794) Improve performance of delete users/groups utility
[ https://issues.apache.org/jira/browse/RANGER-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554775#comment-17554775 ] Velmurugan Periasamy commented on RANGER-3794: -- [~fateh288] - welcome to Ranger community. I have added you as a contributor. You can assign the ticket to yourself. > Improve performance of delete users/groups utility > -- > > Key: RANGER-3794 > URL: https://issues.apache.org/jira/browse/RANGER-3794 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Fateh Singh >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (RANGER-3519) Provide an option to optimize space needed by Trie objects
[ https://issues.apache.org/jira/browse/RANGER-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3519: - Issue Type: Improvement (was: Bug) > Provide an option to optimize space needed by Trie objects > -- > > Key: RANGER-3519 > URL: https://issues.apache.org/jira/browse/RANGER-3519 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > When the number of policies (and/or tagged resources) is large, the data > structures used by Ranger as indexes for policies (and/or tagged resources) > may need a very large heap memory because they are optimized for fast lookup. > It is desirable to be able to configure Ranger to have these structures > optimized for space in order to keep the heap requirements within acceptable > limit at the cost of somewhat slower lookup. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created
[ https://issues.apache.org/jira/browse/RANGER-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-3442: Assignee: Pavi Subenderan > Ranger KMS DAO memory issues when many new keys are created > --- > > Key: RANGER-3442 > URL: https://issues.apache.org/jira/browse/RANGER-3442 > Project: Ranger > Issue Type: Bug > Components: kms >Affects Versions: 2.0.0 >Reporter: Pavi Subenderan >Assignee: Pavi Subenderan >Priority: Major > Attachments: RANGER-3442-entity-manager-clear.patch, kms-key.py > > > We have many keys created in our KMS keystore and recently we found that when > we create new keys, the KMS instances easily hit against the memory limit. > We can reproduce this with a script to call KMS createKey and then > getMetadata for new keys in a loop. Basically we restart our instances and > memory usage is approximately 1.5GB out of 8GB, but after running this script > for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage > does not go back down after that. > I did a heap dump and saw that most of the memory was being retained by > XXRangerKeystore and eclipse EntityManagerImpl. > * org.eclipse.persistence.internal.jpa.EntityManagerImpl > * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork > And the largest shallow size object was char[] with 4GB+... > > *My fix* > I was ultimately able to solve this issue by adding an > getEntityManager().clear() call in BaseDao.java getAllKeys(). > After I added this fix, we can now run as many KMS CreateKey / getMetadata > calls as we want without any increase in memory usage whatsoever. Memory > usage now stays constant at <1.7GB. > My understanding is that Ranger KMS has a many instances of ThreadLocal > EntityManager (160+ according to my heap dump) which each held a cache of the > results for getAllKeys. Since we have so many keys in our KMS, this would > easily put as at the memory limit. > Not sure if there are any drawbacks to clearing EntityManager in > BaseDao.getAllKeys() but we are seeing greatly improved performance in our > case since we aren't constantly hitting the memory limit anymore. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created
[ https://issues.apache.org/jira/browse/RANGER-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516869#comment-17516869 ] Velmurugan Periasamy commented on RANGER-3442: -- [~pavitheran] is added as contributor. Thanks. CC [~dhavalshah9131] / [~spolavarapu] > Ranger KMS DAO memory issues when many new keys are created > --- > > Key: RANGER-3442 > URL: https://issues.apache.org/jira/browse/RANGER-3442 > Project: Ranger > Issue Type: Bug > Components: kms >Affects Versions: 2.0.0 >Reporter: Pavi Subenderan >Assignee: Pavi Subenderan >Priority: Major > Attachments: RANGER-3442-entity-manager-clear.patch, kms-key.py > > > We have many keys created in our KMS keystore and recently we found that when > we create new keys, the KMS instances easily hit against the memory limit. > We can reproduce this with a script to call KMS createKey and then > getMetadata for new keys in a loop. Basically we restart our instances and > memory usage is approximately 1.5GB out of 8GB, but after running this script > for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage > does not go back down after that. > I did a heap dump and saw that most of the memory was being retained by > XXRangerKeystore and eclipse EntityManagerImpl. > * org.eclipse.persistence.internal.jpa.EntityManagerImpl > * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork > And the largest shallow size object was char[] with 4GB+... > > *My fix* > I was ultimately able to solve this issue by adding an > getEntityManager().clear() call in BaseDao.java getAllKeys(). > After I added this fix, we can now run as many KMS CreateKey / getMetadata > calls as we want without any increase in memory usage whatsoever. Memory > usage now stays constant at <1.7GB. > My understanding is that Ranger KMS has a many instances of ThreadLocal > EntityManager (160+ according to my heap dump) which each held a cache of the > results for getAllKeys. Since we have so many keys in our KMS, this would > easily put as at the memory limit. > Not sure if there are any drawbacks to clearing EntityManager in > BaseDao.getAllKeys() but we are seeing greatly improved performance in our > case since we aren't constantly hitting the memory limit anymore. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3692) Ranger cannot connect to the DB when the DB is outaged for a long time
[ https://issues.apache.org/jira/browse/RANGER-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-3692: Assignee: Zilong Zhu > Ranger cannot connect to the DB when the DB is outaged for a long time > -- > > Key: RANGER-3692 > URL: https://issues.apache.org/jira/browse/RANGER-3692 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 2.1.0 >Reporter: Zilong Zhu >Assignee: Zilong Zhu >Priority: Major > > We had a database problem where the database was offline for more than a > week. However ranger connot connect to the DB. > {code:java} > Internal Exception: java.sql.SQLException: Connections could not be acquired > from the underlying database! > [C3P0PooledConnectionPoolManager[identityToken->1hgf80qaljdycrokead8h|73c6299]-HelperThread-#0] > WARN com.mchange.v2.log.slf4j.Slf4jMLog$Slf4jMLogger$WarnLogger > (Slf4jMLog.java:223) - > com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@7179549 -- > Acquisition Attempt Failed!!! Clearing pending acquires. While trying to > acquire a needed new resource, we failed to succeed more than the maximum > number of allowed acquisition attempts (30). Last acquisition attempt > exception: > com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link > failure > [C3P0PooledConnectionPoolManager[identityToken->1hgf80qaljdycrokead8h|73c6299]-HelperThread-#0] > WARN com.mchange.v2.log.slf4j.Slf4jMLog$Slf4jMLogger$WarnLogger > (Slf4jMLog.java:220) - Having failed to acquire a resource, > com.mchange.v2.resourcepool.BasicResourcePool@5efb2b9 is interrupting all > Threads waiting on a resource to check out. Will try again in response to new > client requests. {code} > {code:java} > Internal Exception: java.sql.SQLException: An SQLException was provoked by > the following failure: com.mchange.v2.resourcepool.ResourcePoolException: A > ResourcePool cannot acquire a new resource -- the factory or source appears > to be down. > {code} > I found out that this is a bug in c3p0 0.9.5.3. This bug was resolved in > 0.9.5.4. So I suggest to upgrade the version of c3p0 to 0.9.5.4. > [Force kill acquires by rscadrde · Pull Request #91 · swaldman/c3p0 · > GitHub|https://github.com/swaldman/c3p0/pull/91] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3562) Redesign post commit tasks for updating ref-tables when policy/role is updated
[ https://issues.apache.org/jira/browse/RANGER-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3562: - Fix Version/s: 3.0.0 > Redesign post commit tasks for updating ref-tables when policy/role is updated > -- > > Key: RANGER-3562 > URL: https://issues.apache.org/jira/browse/RANGER-3562 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > If a ranger administrator creates/updates a policy or role, the users and > groups specified in the policy, if not present, are created in a separate > task that is executed after the original transaction is committed. This Jira > addresses improving the structure and design of the post commit tasks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3554) [Intermittent] API call to fetch the list of policies for a particular service repo returns a deleted policy in the response
[ https://issues.apache.org/jira/browse/RANGER-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3554: - Fix Version/s: 3.0.0 > [Intermittent] API call to fetch the list of policies for a particular > service repo returns a deleted policy in the response > > > Key: RANGER-3554 > URL: https://issues.apache.org/jira/browse/RANGER-3554 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > Multiple tests are executed during the test run, and the flow of the tests is > as follows:- > # A set of policies needed for the test are created for a Ranger service. > # Tests are run. > # All existing policies in the Ranger service are deleted by fetching all > policies in the service, and deleting them one-by-one. Each delete call are > successful. > # All policies in the Ranger service are fetched to ensure that no policies > are remaining in the Ranger service. > It is expected that in step 4, no policies are returned. However, > intermittently, step 4 returns policy that is deleted in step 3. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3490) Make policy resource signature is unique in a service
[ https://issues.apache.org/jira/browse/RANGER-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3490: - Fix Version/s: 3.0.0 > Make policy resource signature is unique in a service > - > > Key: RANGER-3490 > URL: https://issues.apache.org/jira/browse/RANGER-3490 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > There may be multiple policies with the same resource signature within a > service (at most one enabled policy and potentially any number of disabled > policies). Therefore, the resource-signature uniqueness within a service > cannot be enforced at the database level. > The proposal is to encode GUID of a disabled policy within the resource > signature, thus making the resource signature unique within a service. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3519) Provide an option to optimize space needed by Trie objects
[ https://issues.apache.org/jira/browse/RANGER-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3519: - Fix Version/s: 3.0.0 > Provide an option to optimize space needed by Trie objects > -- > > Key: RANGER-3519 > URL: https://issues.apache.org/jira/browse/RANGER-3519 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > When the number of policies (and/or tagged resources) is large, the data > structures used by Ranger as indexes for policies (and/or tagged resources) > may need a very large heap memory because they are optimized for fast lookup. > It is desirable to be able to configure Ranger to have these structures > optimized for space in order to keep the heap requirements within acceptable > limit at the cost of somewhat slower lookup. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-2967) Add support for Amazon CloudWatch Logs as an Audit Store
[ https://issues.apache.org/jira/browse/RANGER-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448198#comment-17448198 ] Velmurugan Periasamy commented on RANGER-2967: -- [~yInnovation] - were you able to proceed on this? i.e. testing with other plugins and adding support in Ranger admin server? CC [~abhayk] / [~rmani] / [~spolavarapu] / [~pradeepagrawal8184] > Add support for Amazon CloudWatch Logs as an Audit Store > > > Key: RANGER-2967 > URL: https://issues.apache.org/jira/browse/RANGER-2967 > Project: Ranger > Issue Type: Improvement > Components: audit >Affects Versions: 2.0.0 >Reporter: Yao >Priority: Minor > Labels: newbie, patch-available > Attachments: > 0001-Add-support-for-Amazon-CloudWatch-Logs-as-an-Audit-S.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > This change is to add CloudWatch Logs to the list of Ranger supported audit > stores. With this change, Ranger users will be allowed to configure their > plugins to send audit events to Amazon CloudWatch Logs. Further, customers > can query the events using Amazon CloudWatch Insights. > This functionality is built with a newly introduced audit destination > 'AmazonCloudWatchAuditDestination'. Ranger users can enable it in the way > similar to other types of audit destinations like Solr. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-3469) Off-By-One Error in XUser Syncing
[ https://issues.apache.org/jira/browse/RANGER-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435508#comment-17435508 ] Velmurugan Periasamy commented on RANGER-3469: -- [~belugabehr] - usually reviews go through https://reviews.apache.org/. Are you able to upload your patch there? Please see https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55151244 Thanks. > Off-By-One Error in XUser Syncing > - > > Key: RANGER-3469 > URL: https://issues.apache.org/jira/browse/RANGER-3469 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: David Mollitor >Priority: Minor > > {code:java|title=PolicyMgrUserGroupBuilder.java} > int uploadedCount = -1; > int pageSize = Integer.valueOf(recordsToPullPerCall); > while (uploadedCount < totalCount) { > ... > GetXGroupListResponse pagedXGroupList = new GetXGroupListResponse(); > int pagedXGroupListLen = uploadedCount+pageSize; > > pagedXGroupList.setXgroupInfoList(xGroupList.getXgroupInfoList().subList(uploadedCount+1,pagedXGroupListLen>totalCount?totalCount:pagedXGroupListLen)); > {code} > The size of the first batch of users to sync is: > {code:java} > int uploadedCount = -1; > // default in value is 1000 > int pageSize = Integer.valueOf(recordsToPullPerCall); > // value is 1000 + -1 = 999 > int pagedXGroupListLen = uploadedCount+pageSize; > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3469) Off-By-One Error in XUser Syncing
[ https://issues.apache.org/jira/browse/RANGER-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435478#comment-17435478 ] Velmurugan Periasamy commented on RANGER-3469: -- [~belugabehr] - please create a patch and submit a review in review board. CC [~spolavarapu] > Off-By-One Error in XUser Syncing > - > > Key: RANGER-3469 > URL: https://issues.apache.org/jira/browse/RANGER-3469 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: David Mollitor >Priority: Minor > > {code:java|title=PolicyMgrUserGroupBuilder.java} > int uploadedCount = -1; > int pageSize = Integer.valueOf(recordsToPullPerCall); > while (uploadedCount < totalCount) { > ... > GetXGroupListResponse pagedXGroupList = new GetXGroupListResponse(); > int pagedXGroupListLen = uploadedCount+pageSize; > > pagedXGroupList.setXgroupInfoList(xGroupList.getXgroupInfoList().subList(uploadedCount+1,pagedXGroupListLen>totalCount?totalCount:pagedXGroupListLen)); > {code} > The size of the first batch of users to sync is: > {code:java} > int uploadedCount = -1; > // default in value is 1000 > int pageSize = Integer.valueOf(recordsToPullPerCall); > // value is 1000 + -1 = 999 > int pagedXGroupListLen = uploadedCount+pageSize; > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3500) Ranger policy list doesn't support sorting by field
[ https://issues.apache.org/jira/browse/RANGER-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-3500: Assignee: Xuze Yang > Ranger policy list doesn't support sorting by field > --- > > Key: RANGER-3500 > URL: https://issues.apache.org/jira/browse/RANGER-3500 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 2.1.0 >Reporter: Xuze Yang >Assignee: Xuze Yang >Priority: Major > > When getting the ranger policy list, we may want to sort the returned policy > list according to certain fields, such as policyId, policyName and etc. But > case shows that adding the parameters sortBy and sortType to the url has no > effect (eg: > [http://192.168.0.12:6080/service/plugins/]policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs). > I look through the source code and find that code supports sorting by > fields, but due to some code bugs, it did not really take effect. > The main reason for the problem is that when the SearchFilter is copied > deeply, only the params is copied, the sortBy and sortType attributes is > omitted. The code show as follows: > {code:java} > Map paramsCopy = new HashMap<>(filter.getParams()); > SearchFilter searchFilter = new SearchFilter(paramsCopy); > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3318) Ranger webui main page has a paging limit for services
[ https://issues.apache.org/jira/browse/RANGER-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3318: - Component/s: (was: 2.2.0) > Ranger webui main page has a paging limit for services > -- > > Key: RANGER-3318 > URL: https://issues.apache.org/jira/browse/RANGER-3318 > Project: Ranger > Issue Type: Bug > Components: admin, Ranger >Affects Versions: 2.0.0, 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Priority: Major > > Hi! > It's a bug with webui. We have 100+++ services on our Ranger production, but > webui show only first 100 added. > It's the paging limit without option to list pages. Nice to have - update UI > and implement page numbers. > > Temprorary workaround i find: > Inside the file > {{ranger_admin_directory/ews/webapp/scripts}}/{{Main.min.js}} > all substrings: > “{{this.services.setPageSize(100)}}” > modify just in case for > “{{this.services.setPageSize(200)}}” > > As Idea - you can make this PageSize as ranger option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3319) Ranger usersync cookie default duration for sync
[ https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3319: - Component/s: (was: 2.2.0) > Ranger usersync cookie default duration for sync > > > Key: RANGER-3319 > URL: https://issues.apache.org/jira/browse/RANGER-3319 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1 >Reporter: Konstantin Tsypin >Priority: Major > > Hi! > At this moment we cant initial sync out of the box our LDAP with 10k+ users & > groups. > It's because sync works as three steps: > 1) Sync groups > 2) Sync users > 3) Map users&groups as one request and send it to rangeradmin > From time to time our third step on initial sync generate this single request > for a long time > It can be easily three or four hours. > Acrossing this timegate we have an error with timeout usersync cookie (that > by default is 60 minutes) and failed 3rd step. > > The workaround - is > ranger_admin_directory/ews/webapp/WEB-INF/web.xml > change > default > 60 > to just in case > 1440 > BUT im was really frustrated with this behavior whan faced it first time, and > i want to have a mechanism to split mapping step for a smaller part, and > update cookie from time to time. > > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3383) Internationalization
[ https://issues.apache.org/jira/browse/RANGER-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3383: - Component/s: (was: 2.2.0) > Internationalization > > > Key: RANGER-3383 > URL: https://issues.apache.org/jira/browse/RANGER-3383 > Project: Ranger > Issue Type: Wish > Components: Ranger >Reporter: Egor >Priority: Minor > > Hello, my name is Egor > I’m from Russia and I provide support services for your application > My clients are interested in translation of GUI, so I thought that I can help > you with i18n and translate UI into Russian language > Is there any rules or thoughts how your community is going to > internationalize? > Or is there any person in community with whom I can discuss this Issue? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-2846) Add support for resource[volume, bucket, key] look up in ozone plugin
[ https://issues.apache.org/jira/browse/RANGER-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-2846: - Fix Version/s: 3.0.0 > Add support for resource[volume, bucket, key] look up in ozone plugin > - > > Key: RANGER-2846 > URL: https://issues.apache.org/jira/browse/RANGER-2846 > Project: Ranger > Issue Type: Task > Components: plugins >Affects Versions: 2.1.0 >Reporter: Abhishek Shukla >Assignee: Abhishek Kumar >Priority: Major > Labels: ozone > Fix For: 3.0.0 > > > The task to add support for resource [volume, bucket, key] lookup while > creating ozone policy in ranger. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3481) Incremental policy updates do not work correctly for multiple security zones
[ https://issues.apache.org/jira/browse/RANGER-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3481: - Fix Version/s: 3.0.0 > Incremental policy updates do not work correctly for multiple security zones > > > Key: RANGER-3481 > URL: https://issues.apache.org/jira/browse/RANGER-3481 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > If Ranger has multiple security zones configured and policies from a single > security zone are modified, then the incremental policy update is not > processed correctly which results in incorrect enforcement of policies in > remaining security zones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3462) User with delegated admin permission on a resource cannot fetch policy for the resource
[ https://issues.apache.org/jira/browse/RANGER-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3462: - Fix Version/s: 3.0.0 > User with delegated admin permission on a resource cannot fetch policy for > the resource > --- > > Key: RANGER-3462 > URL: https://issues.apache.org/jira/browse/RANGER-3462 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0 > > > Steps to reproduce the issue: > # Create users in Ranger alice, bob, and charlie. Alice has admin role, bob > and charlie has user role. > # Create an HDFS policy with name "test-delegate-admin" as alice. In that > policy there 2 policy items; one for bob, and the other for alice with RWX > permissions with "Delegate Admin". > # Log in as bob, and edited the policy item for bob: removed Write > permission. > # After saving the policy bob is not able to see to policy anymore. It only > becomes visible after the Write permission is restored. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3462) User with delegated admin permission on a resource cannot fetch policy for the resource
[ https://issues.apache.org/jira/browse/RANGER-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3462: - Fix Version/s: 2.2.0 > User with delegated admin permission on a resource cannot fetch policy for > the resource > --- > > Key: RANGER-3462 > URL: https://issues.apache.org/jira/browse/RANGER-3462 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Steps to reproduce the issue: > # Create users in Ranger alice, bob, and charlie. Alice has admin role, bob > and charlie has user role. > # Create an HDFS policy with name "test-delegate-admin" as alice. In that > policy there 2 policy items; one for bob, and the other for alice with RWX > permissions with "Delegate Admin". > # Log in as bob, and edited the policy item for bob: removed Write > permission. > # After saving the policy bob is not able to see to policy anymore. It only > becomes visible after the Write permission is restored. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created
[ https://issues.apache.org/jira/browse/RANGER-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423009#comment-17423009 ] Velmurugan Periasamy commented on RANGER-3442: -- Please send an email to the dev list with your apache id. I can add you as a contributor. > Ranger KMS DAO memory issues when many new keys are created > --- > > Key: RANGER-3442 > URL: https://issues.apache.org/jira/browse/RANGER-3442 > Project: Ranger > Issue Type: Bug > Components: kms >Affects Versions: 2.0.0 >Reporter: Pavi Subenderan >Priority: Major > Attachments: RANGER-3442-entity-manager-clear.patch > > > We have many keys created in our KMS keystore and recently we found that when > we create new keys, the KMS instances easily hit against the memory limit. > We can reproduce this with a script to call KMS createKey and then > getMetadata for new keys in a loop. Basically we restart our instances and > memory usage is approximately 1.5GB out of 8GB, but after running this script > for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage > does not go back down after that. > I did a heap dump and saw that most of the memory was being retained by > XXRangerKeystore and eclipse EntityManagerImpl. > * org.eclipse.persistence.internal.jpa.EntityManagerImpl > * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork > And the largest shallow size object was char[] with 4GB+... > > *My fix* > I was ultimately able to solve this issue by adding an > getEntityManager().clear() call in BaseDao.java getAllKeys(). > After I added this fix, we can now run as many KMS CreateKey / getMetadata > calls as we want without any increase in memory usage whatsoever. Memory > usage now stays constant at <1.7GB. > My understanding is that Ranger KMS has a many instances of ThreadLocal > EntityManager (160+ according to my heap dump) which each held a cache of the > results for getAllKeys. Since we have so many keys in our KMS, this would > easily put as at the memory limit. > Not sure if there are any drawbacks to clearing EntityManager in > BaseDao.getAllKeys() but we are seeing greatly improved performance in our > case since we aren't constantly hitting the memory limit anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created
[ https://issues.apache.org/jira/browse/RANGER-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422991#comment-17422991 ] Velmurugan Periasamy commented on RANGER-3442: -- Thanks [~pavitheran] for the contribution. Please create a review board request. > Ranger KMS DAO memory issues when many new keys are created > --- > > Key: RANGER-3442 > URL: https://issues.apache.org/jira/browse/RANGER-3442 > Project: Ranger > Issue Type: Bug > Components: kms >Affects Versions: 2.0.0 >Reporter: Pavi Subenderan >Priority: Major > Attachments: RANGER-3442-entity-manager-clear.patch > > > We have many keys created in our KMS keystore and recently we found that when > we create new keys, the KMS instances easily hit against the memory limit. > We can reproduce this with a script to call KMS createKey and then > getMetadata for new keys in a loop. Basically we restart our instances and > memory usage is approximately 1.5GB out of 8GB, but after running this script > for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage > does not go back down after that. > I did a heap dump and saw that most of the memory was being retained by > XXRangerKeystore and eclipse EntityManagerImpl. > * org.eclipse.persistence.internal.jpa.EntityManagerImpl > * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork > And the largest shallow size object was char[] with 4GB+... > > *My fix* > I was ultimately able to solve this issue by adding an > getEntityManager().clear() call in BaseDao.java getAllKeys(). > After I added this fix, we can now run as many KMS CreateKey / getMetadata > calls as we want without any increase in memory usage whatsoever. Memory > usage now stays constant at <1.7GB. > My understanding is that Ranger KMS has a many instances of ThreadLocal > EntityManager (160+ according to my heap dump) which each held a cache of the > results for getAllKeys. Since we have so many keys in our KMS, this would > easily put as at the memory limit. > Not sure if there are any drawbacks to clearing EntityManager in > BaseDao.getAllKeys() but we are seeing greatly improved performance in our > case since we aren't constantly hitting the memory limit anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3211) Upgrade libthrift to 0.14.1
[ https://issues.apache.org/jira/browse/RANGER-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3211: - Fix Version/s: (was: 2.2.0) > Upgrade libthrift to 0.14.1 > --- > > Key: RANGER-3211 > URL: https://issues.apache.org/jira/browse/RANGER-3211 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Mahesh Hanumant Bandal >Assignee: Mahesh Hanumant Bandal >Priority: Major > Fix For: 3.0.0 > > > Ranger is pulling in Thrift 0.13.0 and should be upgraded to 0.14.1 for best > practices. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (RANGER-3211) Upgrade libthrift to 0.14.1
[ https://issues.apache.org/jira/browse/RANGER-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reopened RANGER-3211: -- > Upgrade libthrift to 0.14.1 > --- > > Key: RANGER-3211 > URL: https://issues.apache.org/jira/browse/RANGER-3211 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Mahesh Hanumant Bandal >Assignee: Mahesh Hanumant Bandal >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Ranger is pulling in Thrift 0.13.0 and should be upgraded to 0.14.1 for best > practices. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3397) Update ACL computation to (optionally) expand Ranger Roles to users and groups and include chained-plugins in ACL computation
[ https://issues.apache.org/jira/browse/RANGER-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3397: - Fix Version/s: 2.2.0 3.0.0 > Update ACL computation to (optionally) expand Ranger Roles to users and > groups and include chained-plugins in ACL computation > - > > Key: RANGER-3397 > URL: https://issues.apache.org/jira/browse/RANGER-3397 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Currently, getResourceACLs() API does not include chained-plugins into its > computation. Also, as users and groups for a given Ranger Role can be > completely resolved using Ranger's own database, it is useful to optionally > expand Roles to their constituent users and groups and report ACLs for users > and groups only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3371) Update algorithm to build Ranger policy-database object from Ranger policy-view object
[ https://issues.apache.org/jira/browse/RANGER-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3371: - Fix Version/s: 2.2.0 3.0.0 > Update algorithm to build Ranger policy-database object from Ranger > policy-view object > -- > > Key: RANGER-3371 > URL: https://issues.apache.org/jira/browse/RANGER-3371 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > The algorithm to build Ranger policy database object from the Ranger policy > view object leaves some fields (guid, policy-type, etc.) un-initialized > during policy creation. Values of all fields whose values are known when > database policy object was created need to be initialized so that the > policy_text field-value can be used to recreate the original policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3148) Ranger HDFS plugin to audit chmod and chown operations
[ https://issues.apache.org/jira/browse/RANGER-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3148: - Reporter: suja s (was: Ramesh Mani) > Ranger HDFS plugin to audit chmod and chown operations > -- > > Key: RANGER-3148 > URL: https://issues.apache.org/jira/browse/RANGER-3148 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: suja s >Assignee: Ramesh Mani >Priority: Minor > Fix For: 2.2.0 > > Attachments: Screen Shot 2021-03-23 at 11.38.22 PM.png > > > Ranger auditing not happening for hdfs chown and chmod operations, even > though ranger authorizes it. > chown can only be done by super user in hdfs and hence ranger authorization > for this will be non-determined and falls back to hdfs for superuser access > check. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3350) Ranger HivePluginAuthorizer SHOW CURRENT ROLES not fetching the role set in current hive beeline session
[ https://issues.apache.org/jira/browse/RANGER-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3350: - Reporter: suja s (was: Ramesh Mani) > Ranger HivePluginAuthorizer SHOW CURRENT ROLES not fetching the role set in > current hive beeline session > - > > Key: RANGER-3350 > URL: https://issues.apache.org/jira/browse/RANGER-3350 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: suja s >Priority: Minor > Fix For: 2.2.0 > > > Ranger HivePluginAuthorizer SHOW CURRENT ROLES not fetching the role set in > current hive beeline session. User has to open a new session to show current > roles assigned to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3353) Show roles is not listing all roles
[ https://issues.apache.org/jira/browse/RANGER-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3353: - Reporter: suja s (was: Ramesh Mani) > Show roles is not listing all roles > --- > > Key: RANGER-3353 > URL: https://issues.apache.org/jira/browse/RANGER-3353 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: suja s >Assignee: Ramesh Mani >Priority: Major > Fix For: 2.2.0 > > > Currently SHOW ROLES showing only the current users roles and to have the > parity with Hive, SHOW ROLEs should show all the roles maintained in Ranger > and it can be executed by SERVICE ADMIN or ADMIN user -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3194) Ranger Access Audits page not loading
[ https://issues.apache.org/jira/browse/RANGER-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3194: - Fix Version/s: 2.2.0 > Ranger Access Audits page not loading > - > > Key: RANGER-3194 > URL: https://issues.apache.org/jira/browse/RANGER-3194 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Assignee: Kishor Gollapalliwar >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Ranger Access Audits page stop loading after few days. The jstack trace > suggest threads keep getting blocked on solr client which trying to fetch > records from solr collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3351) Incorrect hive query displayed for grant and revoke role command
[ https://issues.apache.org/jira/browse/RANGER-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3351: - Reporter: suja s (was: Pradeep Agrawal) > Incorrect hive query displayed for grant and revoke role command > > > Key: RANGER-3351 > URL: https://issues.apache.org/jira/browse/RANGER-3351 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Assignee: Pradeep Agrawal >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3351-Incorrect-hive-query-displayed-for-grant.patch, revoke.png > > > Invoke command "revoke from user on hive side. > Expected > Hive query that is given for execution should be displayed under ranger > access audits > Actual > Hive query shows revoke but the query is changed > > !revoke.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3194) Ranger Access Audits page not loading
[ https://issues.apache.org/jira/browse/RANGER-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3194: - Reporter: suja s (was: Kishor Gollapalliwar) > Ranger Access Audits page not loading > - > > Key: RANGER-3194 > URL: https://issues.apache.org/jira/browse/RANGER-3194 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Assignee: Kishor Gollapalliwar >Priority: Major > Fix For: 3.0.0 > > > Ranger Access Audits page stop loading after few days. The jstack trace > suggest threads keep getting blocked on solr client which trying to fetch > records from solr collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3342) Need to make the Ranger embedded server work directory configurable
[ https://issues.apache.org/jira/browse/RANGER-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3342: - Fix Version/s: 2.2.0 > Need to make the Ranger embedded server work directory configurable > --- > > Key: RANGER-3342 > URL: https://issues.apache.org/jira/browse/RANGER-3342 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: 2.1.0, 3.0.0 >Reporter: Vishal Suvagia >Assignee: Vishal Suvagia >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: RANGER-3342.01.patch, RANGER-3342.02.patch, > RANGER-3342.patch > > > Currently the work directory for Ranger embedded server is not configurable. > Need to make the work directory configurable to a custom location so that > user can customize if required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3342) Need to make the Ranger embedded server work directory configurable
[ https://issues.apache.org/jira/browse/RANGER-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3342: - Fix Version/s: 3.0.0 > Need to make the Ranger embedded server work directory configurable > --- > > Key: RANGER-3342 > URL: https://issues.apache.org/jira/browse/RANGER-3342 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: 2.1.0, 3.0.0 >Reporter: Vishal Suvagia >Assignee: Vishal Suvagia >Priority: Major > Fix For: 3.0.0 > > Attachments: RANGER-3342.01.patch, RANGER-3342.02.patch, > RANGER-3342.patch > > > Currently the work directory for Ranger embedded server is not configurable. > Need to make the work directory configurable to a custom location so that > user can customize if required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3349) Handling multiple grant role command for same user
[ https://issues.apache.org/jira/browse/RANGER-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3349: - Reporter: suja s (was: Dineshkumar Yadav) > Handling multiple grant role command for same user > -- > > Key: RANGER-3349 > URL: https://issues.apache.org/jira/browse/RANGER-3349 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: suja s >Assignee: Dineshkumar Yadav >Priority: Major > > Scenario: > 1. User testuser1 is an admin on ranger side > 2. Open a hive beeline session as testuser1 > 3. Create role r1 > role r1 is created on ranger side with testuser1 as admin user for the role > 4. Execute command "grant r1 to user testuser1" > Expected - r1 should have no changes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3343) Ranger policy cache is incorrect in some scenario
[ https://issues.apache.org/jira/browse/RANGER-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3343: - Fix Version/s: 2.2.0 3.0.0 > Ranger policy cache is incorrect in some scenario > - > > Key: RANGER-3343 > URL: https://issues.apache.org/jira/browse/RANGER-3343 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Steps are : # There are two external users : diasmi(user role) and > diasmi_admin (admin role). > # diasmi is granted a delegated admin privilege on some resource. > # Log in to Ranger admin GUI from as diasmi_admin and change the policy > (first policy item) for the resource. > # Wait for policy sync. policy cache json is correct and it has both policy > item entries. > # Log in to Ranger admin GUI as diasmi user and change the policy to add > another policy item (second policy-item) with the delegated-admin box > unchecked. > # Wait for policy sync. policy cache json is incorrect and it has only first > policy item entry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3122) Support delegate-admin for specific permissions
[ https://issues.apache.org/jira/browse/RANGER-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3122: - Fix Version/s: 2.2.0 3.0.0 > Support delegate-admin for specific permissions > --- > > Key: RANGER-3122 > URL: https://issues.apache.org/jira/browse/RANGER-3122 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Currently delegate-admin cannot be marked for specific permissions. It is > all-or-nothing for the permissions defined in resource policy. Ranger should > have ability for granting delegate-admin for specific permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3337) Ranger policy not taking effect with HDFS Snapshots
[ https://issues.apache.org/jira/browse/RANGER-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3337: - Fix Version/s: 2.2.0 3.0.0 > Ranger policy not taking effect with HDFS Snapshots > --- > > Key: RANGER-3337 > URL: https://issues.apache.org/jira/browse/RANGER-3337 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Steps to reproduce the issue: > Step 1 > == > Create a new HDFS policy in Ranger. > Policy Details: > - Policy Name: testcase > - Resource Path: /testcase > Allow Conditions: > - Select User: testuser > - Enabled: yes > - Recursive: yes > - Audit Logging: yes > - Permissions: Read, Write, Execute > Make a note of the Policy ID of the new policy. In my case, it was Policy ID > 1976. > Note that "testuser" should be a non-privileged account. On my cluster I'm > using "testuser", but you may choose something different. > Step 2 > == > Run the following commands whilst authenticated as the "hdfs" superuser: > $ hdfs dfs -mkdir -p /testcase/dir1 > $ hdfs dfsadmin -allowSnapshot /testcase > $ hdfs dfs -createSnapshot /testcase s1 > Step 3 > == > Run the following commands whilst authenticated as the "testuser" user: > $ hdfs dfs -ls /testcase > $ hdfs dfs -ls /testcase/dir1 > $ hdfs dfs -ls /testcase/.snapshot/s1 > NOTE: you might get a permission denied error when you run "hdfs dfs -ls > /testcase/.snapshot/s1". For the purposes of this test case, it does not > matter whether the command succeeds > Step 4 > == > Review the Ranger audit log for the 3 commands you just ran to notice the > following: > - The policy id in first command (hdfs dfs -ls /testcase) is the policy id > of the policy created in step 1, e.g. 1976 > - The policy id in second command (hdfs dfs -ls /testcase/dir1) is the > policy id for the policy created in step 1, e.g. 1976 > - The policy id in the third command (hdfs dfs -ls /testcase/.snapshot/s1) > is "-1", e.g. Ranger did not find a matching policy > Therefore, Ranger HDFS policy is not evaluated for HDFS snapshots. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3323) Ranger Hive Table lookup is not working.
[ https://issues.apache.org/jira/browse/RANGER-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3323: - Fix Version/s: 2.2.0 3.0.0 > Ranger Hive Table lookup is not working. > > > Key: RANGER-3323 > URL: https://issues.apache.org/jira/browse/RANGER-3323 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3323.patch > > > Ranger Hive table lookup is failing with the below error message. > {code:java} > 2021-06-23 09:13:36,206 INFO > org.apache.hadoop.hive.metastore.thrift.TCustomSocket: [main]: Buffer size > for TSocket is: 8192 > 2021-06-23 09:13:36,211 INFO org.apache.hadoop.hive.metastore.HiveMetaStore: > [pool-10-thread-74]: 51: get_multi_table : db={ tbls=null > 2021-06-23 09:13:36,211 INFO > org.apache.hadoop.hive.metastore.HiveMetaStore.audit: [pool-10-thread-74]: > ugi=rangerlookup/mmrngrhive-1.mmrngrhive.root.hwx.s...@root.hwx.site > ip=172.27.28.139cmd=get_multi_table : db={ tbls=null > 2021-06-23 09:13:36,212 INFO org.apache.hadoop.hive.metastore.HiveMetaStore: > [pool-10-thread-74]: 51: Opening raw store with implementation > class:org.apache.hadoop.hive.metastore.ObjectStore > 2021-06-23 09:13:36,213 INFO org.apache.hadoop.hive.metastore.ObjectStore: > [pool-10-thread-74]: RawStore: > org.apache.hadoop.hive.metastore.ObjectStore@619f1981, with > PersistenceManager: null will be shutdown > 2021-06-23 09:13:36,214 INFO org.apache.hadoop.hive.metastore.ObjectStore: > [pool-10-thread-74]: RawStore: > org.apache.hadoop.hive.metastore.ObjectStore@619f1981, with > PersistenceManager: org.datanucleus.api.jdo.JDOPersistenceManager@60bbf86c > created in the thread with id: 292 > 2021-06-23 09:13:36,216 INFO org.apache.hadoop.hive.metastore.HiveMetaStore: > [pool-10-thread-74]: Created RawStore: > org.apache.hadoop.hive.metastore.ObjectStore@619f1981 from thread id: 292 > 2021-06-23 09:13:36,219 WARN org.apache.hadoop.hive.metastore.ObjectStore: > [pool-10-thread-74]: Failed to get database hive.{, returning > NoSuchObjectException > 2021-06-23 09:13:36,219 ERROR > org.apache.hadoop.hive.metastore.RetryingHMSHandler: [pool-10-thread-74]: > UnknownDBException(message:Could not find database hive.{: {) > at > org.apache.hadoop.hive.metastore.ObjectStore.getTableObjectsByName(ObjectStore.java:2255) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.hadoop.hive.metastore.RawStoreProxy.invoke(RawStoreProxy.java:97) > at com.sun.proxy.$Proxy32.getTableObjectsByName(Unknown Source) > at > org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getTableObjectsInternal(HiveMetaStore.java:3773) > at > org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table_objects_by_name_req(HiveMetaStore.java:3740) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.hadoop.hive.metastore.RetryingHMSHandler.invokeInternal(RetryingHMSHandler.java:160) > at > org.apache.hadoop.hive.metastore.RetryingHMSHandler.invoke(RetryingHMSHandler.java:121) > at com.sun.proxy.$Proxy41.get_table_objects_by_name_req(Unknown Source) > at > org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Processor$get_table_objects_by_name_req.getResult(ThriftHiveMetastore.java:18454) > at > org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Processor$get_table_objects_by_name_req.getResult(ThriftHiveMetastore.java:18438) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) > at > org.apache.hadoop.hive.metastore.security.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor$1.run(HadoopThriftAuthBridge.java:643) > at > org.apache.hadoop.hive.metastore.security.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor$1.run(HadoopThriftAuthBridge.java:638) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at > org.apache.hadoop.security.UserGroupInform
[jira] [Updated] (RANGER-3284) Simplify processing of tasks scheduled to execute after current transaction is completed
[ https://issues.apache.org/jira/browse/RANGER-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3284: - Fix Version/s: 2.2.0 3.0.0 > Simplify processing of tasks scheduled to execute after current transaction > is completed > > > Key: RANGER-3284 > URL: https://issues.apache.org/jira/browse/RANGER-3284 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Some tasks, such as updating policy/tag versions of a service after a > policy/tag is updated, are scheduled to run after the transaction changing > policy/tag is completed. The scheduling and execution of such tasks is > complicated and can be simplified. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3103) Ranger KMS should log full UGI principal
[ https://issues.apache.org/jira/browse/RANGER-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3103: - Fix Version/s: 2.2.0 3.0.0 > Ranger KMS should log full UGI principal > > > Key: RANGER-3103 > URL: https://issues.apache.org/jira/browse/RANGER-3103 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Dhaval Shah >Assignee: Mateen Mansoori >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Kms-audit log only logs the short username: > {{OK[op=GENERATE_EEK, key=key1, user=hdfs, accessCount=4206, > interval=10427ms]}} > In this example, it's impossible to tell which NN(s) requested EDEKs when > they are all lumped together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3294) AccessResult attribute with isAudited as false not filtered in Ranger Audit Filter
[ https://issues.apache.org/jira/browse/RANGER-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3294: - Fix Version/s: 2.2.0 3.0.0 > AccessResult attribute with isAudited as false not filtered in Ranger Audit > Filter > --- > > Key: RANGER-3294 > URL: https://issues.apache.org/jira/browse/RANGER-3294 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.2.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > AccessResult attribute with isAudited as false not filtered in Ranger Audit > Filter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3253) Make incremental policy change computation more resilient
[ https://issues.apache.org/jira/browse/RANGER-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3253: - Fix Version/s: 2.2.0 3.0.0 > Make incremental policy change computation more resilient > - > > Key: RANGER-3253 > URL: https://issues.apache.org/jira/browse/RANGER-3253 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Ranger admin, when incremental policies are enabled, retrieves changes to > policies from database since last provided policy-version and applies these > changes on the cached policies to compute new set of policies. This > computation needs to be more resilient - for example - if a change suggests > that a policy is created, but it already exists in the policy-cache, then it > should not be added again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3238) Incorrect response for 'ranger_metric denyconditions' in Collect Diagnostic Data
[ https://issues.apache.org/jira/browse/RANGER-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3238: - Fix Version/s: 2.2.0 > Incorrect response for 'ranger_metric denyconditions' in Collect Diagnostic > Data > > > Key: RANGER-3238 > URL: https://issues.apache.org/jira/browse/RANGER-3238 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Bhagyashri Kokate >Assignee: Bhagyashri Kokate >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: RANGER-3238_V4.patch > > > Getting incorrect response for 'ranger_metric denyconditions' it is > collecting denycondition only from unzone policy. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3262) Ranger group memberships are not working for LDAP sync
[ https://issues.apache.org/jira/browse/RANGER-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3262: - Fix Version/s: 2.2.0 3.0.0 > Ranger group memberships are not working for LDAP sync > -- > > Key: RANGER-3262 > URL: https://issues.apache.org/jira/browse/RANGER-3262 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3262-Fixed-issue-where-group-memberships-are-.patch > > > In order to sync group memberships from LDAP, usersync uses the value > configured for "ranger.usersync.group.memberattributename" (generally it is > memberUid in case of LDAP). In majority of LDAP servers, memberUid typically > returns the shortname of the user. This was causing an issue while computing > group membership in usersync. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3277) Number of users/groups marked for delete are not shown in logs
[ https://issues.apache.org/jira/browse/RANGER-3277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3277: - Reporter: Deepesh Joshi (was: Sailaja Polavarapu) > Number of users/groups marked for delete are not shown in logs > -- > > Key: RANGER-3277 > URL: https://issues.apache.org/jira/browse/RANGER-3277 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > > When usersync computes users/groups that are deleted and the sync source, > this information is not logged in the usersync logs or usersync audits that > are shown in ranger UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3272) Zone tag policies are getting deleted when zone is updated
[ https://issues.apache.org/jira/browse/RANGER-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3272: - Reporter: Harshal Chavan (was: Mateen N Mansoori) > Zone tag policies are getting deleted when zone is updated > -- > > Key: RANGER-3272 > URL: https://issues.apache.org/jira/browse/RANGER-3272 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Priority: Major > > Zone tag policies are getting deleted when zone is updated > Steps to reproduce : > 1.Create a zone with tag service and some service like yarn service. > 2.Create a tag policy in zone > 3.Edit the zone by adding new service like hive service with existing service. > 4.Click on save > 5.Check the tag policy created in step 2. The tag policy gets deleted -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (RANGER-3272) Zone tag policies are getting deleted when zone is updated
[ https://issues.apache.org/jira/browse/RANGER-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy reassigned RANGER-3272: Assignee: Mateen Mansoori > Zone tag policies are getting deleted when zone is updated > -- > > Key: RANGER-3272 > URL: https://issues.apache.org/jira/browse/RANGER-3272 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Mateen Mansoori >Priority: Major > > Zone tag policies are getting deleted when zone is updated > Steps to reproduce : > 1.Create a zone with tag service and some service like yarn service. > 2.Create a tag policy in zone > 3.Edit the zone by adding new service like hive service with existing service. > 4.Click on save > 5.Check the tag policy created in step 2. The tag policy gets deleted -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3192) Use read-write locks for managing access to policy-engine and tag-repository
[ https://issues.apache.org/jira/browse/RANGER-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3192: - Fix Version/s: 2.2.0 3.0.0 > Use read-write locks for managing access to policy-engine and tag-repository > > > Key: RANGER-3192 > URL: https://issues.apache.org/jira/browse/RANGER-3192 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Use concurrent read-write lock to ensure that access evaluation and > policy/tag updates are mutually exclusive in multi-threaded environment > Ranger uses copy and switch method to handle reads and writes to policy and > tag repositories in a multi-threaded environment. Using read/write lock to > handle concurrent accesses will save on copy which is more memory and CPU > efficient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3199) illegal reflective access operation warning in KMS catalina.out logs
[ https://issues.apache.org/jira/browse/RANGER-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3199: - Fix Version/s: 2.2.0 3.0.0 > illegal reflective access operation warning in KMS catalina.out logs > > > Key: RANGER-3199 > URL: https://issues.apache.org/jira/browse/RANGER-3199 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Mahesh Hanumant Bandal >Assignee: Mahesh Hanumant Bandal >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > > following logs are observed in catalina.out file of ranger-kms while using > JDK-11: > {code:java} > INFO: Initiating Jersey application, version 'Jersey: 1.19.3 10/24/2016 03:43 > PM' > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1 jaxb-impl-2.2.3-1.jar) to > method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) > WARNING: Please consider reporting this to the maintainers of > com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > {code} > Need to fix this warning logs. > *This fix should be provided from the maintainers of "com.sun.xml.bind" i.e. > Oracle Corporation. Affected jar is "jaxb-impl-2.2.3-1.jar". This jar is > inherited from "jersey-json-1.19.3.jar".* > > Workaround for this issue : > * +To avoid this warning logs we can add dependency for jaxb-impl-2.3.3.jar+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3208) NPE in Ranger policy engine when processing SELF_OR_CHILD scoped search
[ https://issues.apache.org/jira/browse/RANGER-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3208: - Fix Version/s: 2.2.0 3.0.0 > NPE in Ranger policy engine when processing SELF_OR_CHILD scoped search > --- > > Key: RANGER-3208 > URL: https://issues.apache.org/jira/browse/RANGER-3208 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > The following is the stack trace seen when Ranger policy engine searches Trie > object with SELF_OR_CHILD scope. > > java.lang.NullPointerException at > java.util.AbstractCollection.addAll(AbstractCollection.java:343) at > org.apache.ranger.plugin.policyengine.RangerResourceTrie$TrieNode.collectChildEvaluators(RangerResourceTrie.java:1161) > at > org.apache.ranger.plugin.policyengine.RangerResourceTrie.lambda$getEvaluatorsForResource$0(RangerResourceTrie.java:604) > at > java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1628) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > org.apache.ranger.plugin.policyengine.RangerResourceTrie.getEvaluatorsForResource(RangerResourceTrie.java:604) > at > org.apache.ranger.plugin.policyengine.RangerResourceTrie.getEvaluatorsForResource(RangerResourceTrie.java:180) > at > org.apache.ranger.plugin.policyengine.RangerPolicyRepository.getLikelyMatchPolicyEvaluators(RangerPolicyRepository.java:811) > at > org.apache.ranger.plugin.policyengine.RangerPolicyRepository.getLikelyMatchAccessPolicyEvaluators(RangerPolicyRepository.java:764) > at > org.apache.ranger.plugin.policyengine.RangerPolicyRepository.getLikelyMatchPolicyEvaluators(RangerPolicyRepository.java:741) > at > org.apache.ranger.plugin.policyengine.RangerPolicyEngineImpl.evaluatePoliciesNoAudit(RangerPolicyEngineImpl.java:585) > at > org.apache.ranger.plugin.policyengine.RangerPolicyEngineImpl.zoneAwareAccessEvaluationWithNoAudit(RangerPolicyEngineImpl.java:486) > at > org.apache.ranger.plugin.policyengine.RangerPolicyEngineImpl.evaluatePolicies(RangerPolicyEngineImpl.java:110) > at > org.apache.ranger.plugin.service.RangerBasePlugin.isAccessAllowed(RangerBasePlugin.java:356) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3147) enhance resource-trie to enable finding evaluators for a given resource and its children
[ https://issues.apache.org/jira/browse/RANGER-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3147: - Fix Version/s: 2.2.0 3.0.0 > enhance resource-trie to enable finding evaluators for a given resource and > its children > > > Key: RANGER-3147 > URL: https://issues.apache.org/jira/browse/RANGER-3147 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > For the resource modeled as a path (with a path separator configured in its > definition) it may be desired to search its Trie data to find an exact match > for the resource being searched and its children. Ranger access requests need > to support an additional scope specification (such as SELF_OR_CHILD) to > implement this feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3224) Not able to delete security-zone
[ https://issues.apache.org/jira/browse/RANGER-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3224: - Fix Version/s: 2.2.0 3.0.0 > Not able to delete security-zone > > > Key: RANGER-3224 > URL: https://issues.apache.org/jira/browse/RANGER-3224 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Steps > 1. Create a security zone and have a tag service associated with it. > 2. Create a tag policy in the tag service for the security zone. > 3. Edit security zone to remove tag service association. > 4. Now, try to delete the security zone. > Zone deletion fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3202) Ranger KMS - Upgrade api-i18n jar from 1.0.0-M20 to 1.0.2+
[ https://issues.apache.org/jira/browse/RANGER-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3202: - Fix Version/s: 2.2.0 3.0.0 > Ranger KMS - Upgrade api-i18n jar from 1.0.0-M20 to 1.0.2+ > -- > > Key: RANGER-3202 > URL: https://issues.apache.org/jira/browse/RANGER-3202 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Dhaval Shah >Assignee: Dhaval Shah >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Currently in Ranger KMS we have api-i18n jar v 1.0.0-M20. This should be > upgraded to 1.0.2 or later. > Github : https://github.com/apache/ranger/blob/master/kms/pom.xml#L384 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-980) User sync does not delete users if they do not exist anymore
[ https://issues.apache.org/jira/browse/RANGER-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-980: Fix Version/s: 2.2.0 3.0.0 > User sync does not delete users if they do not exist anymore > > > Key: RANGER-980 > URL: https://issues.apache.org/jira/browse/RANGER-980 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 0.6.0, 0.5.3 >Reporter: Bolke de Bruin >Assignee: Sailaja Polavarapu >Priority: Critical > Labels: security > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-980-Support-for-deleted-users-groups-in-Range.patch, > 0001-RANGER-980-User-sync-does-not-delete-users-if-they-d.patch, Deleted > users and groups support in Ranger (RANGER-980).pdf, RANGER-980.patch > > > usersync for all sources creates users and groups, but does not delete them > from Ranger's database if these users and groups do not exists anymore in the > original source. > So if you have for example a user called "bob" and bob leaves the company his > access rights will continue to exist in Ranger. If a new employee comes in > that is also "bob" he is immediately granted the same access as the previous > employee. This creates security incidents. > In a reasonable complex company it cannot be expected that another user > administration is being taken care of, while deletion could and should happen > automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3250) Add relevant indexes to database table to speed up ingress processing of tagged entities
[ https://issues.apache.org/jira/browse/RANGER-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3250: - Fix Version/s: 2.2.0 3.0.0 > Add relevant indexes to database table to speed up ingress processing of > tagged entities > > > Key: RANGER-3250 > URL: https://issues.apache.org/jira/browse/RANGER-3250 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Tagged entities are persisted in a Relational database table. During ingress > of tagged entities, Ranger admin needs to look up this table. Indexing the > table on the columns that are used for look-up will speed up ingress rate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3157) Improvements for audit details page part-2
[ https://issues.apache.org/jira/browse/RANGER-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3157: - Fix Version/s: 2.2.0 3.0.0 > Improvements for audit details page part-2 > -- > > Key: RANGER-3157 > URL: https://issues.apache.org/jira/browse/RANGER-3157 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3157.patch > > > Audit --> Access tab > 1) Include policy details, after the table showing audit log details. > Contents of policy details should be similar to the one shown on clicking > policy-id in audit logs listing page. > 2) given audit log details are likely to be used in compliance, it will help > to include following at the bottom of this page: > * Generated by: > * Generated on: like: Jan 11, 2021, 11:52 AM EST > * User IP address: > * Ranger Admin URL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3228) Improvement in audit filter feature
[ https://issues.apache.org/jira/browse/RANGER-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3228: - Fix Version/s: 2.2.0 3.0.0 > Improvement in audit filter feature > --- > > Key: RANGER-3228 > URL: https://issues.apache.org/jira/browse/RANGER-3228 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3228.patch, 0002-RANGER-3228.patch > > > 1)In tag service permission for audit filter not populate properly. > 2) Show audit filter data in readable format instead of just json value in > service detail view popup. > 3)When Save the Resources and then click on Cancel icon then there should be > Add icon besides it instead of Edit iocn. > 4)When I do delete audit filter then there should be message under audit > filter required saying:No Audit filter Data Found.!! > 5)Observed that there is no select dropdown for the operations column while > configuring audit filters. While the placeholder hint is displayed as Select > Action. we should add an apt placeholder/tooltip with a message like, "Type > Action Name". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3186) [Ranger Access Audit Improvement]Changes done from one user, persists for other users as well.
[ https://issues.apache.org/jira/browse/RANGER-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3186: - Fix Version/s: 2.2.0 3.0.0 > [Ranger Access Audit Improvement]Changes done from one user, persists for > other users as well. > -- > > Key: RANGER-3186 > URL: https://issues.apache.org/jira/browse/RANGER-3186 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3186.patch > > > Steps to reproduce :- > 1. Login with admin user. > 2. Add one user with admin role. > 3. On ranger access audit deselect some column. > 4. Logout from admin user and login with new user created. > 5. Go to access audit page, you will see the changes are still present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3239) Ranger : Add checkbox for default audit filters on Service Creation page
[ https://issues.apache.org/jira/browse/RANGER-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3239: - Fix Version/s: 2.2.0 3.0.0 > Ranger : Add checkbox for default audit filters on Service Creation page > > > Key: RANGER-3239 > URL: https://issues.apache.org/jira/browse/RANGER-3239 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3239.patch > > > Introduce check box in service creation page on UI. Based on the checkbox, > will decide addition/removal of audit filters at the time of service creation. > * By default checkbox will be checked and will show default audit filters in > the audit filter section of the service creation page. > * When the user unchecked the checkbox, audit filters won't be shown on the > screen and it will not be persisted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3240) Show Latest Response from Server on all pages of Ranger UI.
[ https://issues.apache.org/jira/browse/RANGER-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3240: - Fix Version/s: 2.2.0 3.0.0 > Show Latest Response from Server on all pages of Ranger UI. > --- > > Key: RANGER-3240 > URL: https://issues.apache.org/jira/browse/RANGER-3240 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3240.patch > > > Suggestion for Improvement on Ranger UI : > The text should show the timestamp of the most recent response from the > server. Needs to be done for all pages in UI as part of Header. > * Generated on: like: Jan 11, 2021, 11:52 AM EST -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-2924) [Ranger Latest Admin UI] Security Zones are not clickable to select different security zones
[ https://issues.apache.org/jira/browse/RANGER-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-2924: - Fix Version/s: (was: 2.2.0) (was: 3.0.0) 2.1.0 > [Ranger Latest Admin UI] Security Zones are not clickable to select different > security zones > > > Key: RANGER-2924 > URL: https://issues.apache.org/jira/browse/RANGER-2924 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 2.1.0 >Reporter: Abhishek Shukla >Priority: Major > Labels: ranger > Fix For: 2.1.0 > > Attachments: Screenshot 2020-07-24 at 1.25.54 PM.png > > > Observed that in the New Ranger Admin UI, Security Zones Page, we are not > able to click on different security zones in the sidebar. > !Screenshot 2020-07-24 at 1.25.54 PM.png|width=301,height=175! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-2924) [Ranger Latest Admin UI] Security Zones are not clickable to select different security zones
[ https://issues.apache.org/jira/browse/RANGER-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-2924: - Fix Version/s: 2.2.0 3.0.0 > [Ranger Latest Admin UI] Security Zones are not clickable to select different > security zones > > > Key: RANGER-2924 > URL: https://issues.apache.org/jira/browse/RANGER-2924 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 2.1.0 >Reporter: Abhishek Shukla >Priority: Major > Labels: ranger > Fix For: 3.0.0, 2.2.0 > > Attachments: Screenshot 2020-07-24 at 1.25.54 PM.png > > > Observed that in the New Ranger Admin UI, Security Zones Page, we are not > able to click on different security zones in the sidebar. > !Screenshot 2020-07-24 at 1.25.54 PM.png|width=301,height=175! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3120) [Ranger Latest UI] Long tag based service names are not shown correctly
[ https://issues.apache.org/jira/browse/RANGER-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3120: - Fix Version/s: 2.2.0 3.0.0 > [Ranger Latest UI] Long tag based service names are not shown correctly > --- > > Key: RANGER-3120 > URL: https://issues.apache.org/jira/browse/RANGER-3120 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Abhishek Shukla >Assignee: Dhaval Rajpara >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3120.patch, 0002-RANGER-3120.patch, > tag_based_policy_latest_ranger_ui.png > > > Observed that with Ranger Latest UI, the Tag Policies page is not able to > display service names with long names correctly, it overlaps with other > service names. > Attached screenshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3242) Need feature to make the access log file name configurable for user
[ https://issues.apache.org/jira/browse/RANGER-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3242: - Fix Version/s: 2.2.0 3.0.0 > Need feature to make the access log file name configurable for user > --- > > Key: RANGER-3242 > URL: https://issues.apache.org/jira/browse/RANGER-3242 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 2.2.0, 2.1.1, 2.10 >Reporter: Vishal Suvagia >Assignee: Vishal Suvagia >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > Attachments: RANGER-3242.patch > > > Currently the access log file name is set as default, need feature to have it > customizable for the user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3130) [Ranger Admin UI] Improvement in Ranger Latest UI's Edit Policy Page
[ https://issues.apache.org/jira/browse/RANGER-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3130: - Fix Version/s: 2.2.0 3.0.0 > [Ranger Admin UI] Improvement in Ranger Latest UI's Edit Policy Page > > > Key: RANGER-3130 > URL: https://issues.apache.org/jira/browse/RANGER-3130 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Abhishek Shukla >Assignee: Dhaval Rajpara >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3130.patch, With Sidebar.png, Without > Sidebar.png > > > Observed that there are some issues related to button alignment in the Ranger > Admin UI's Edit Policy Page. > * On closing the sidebar, the Enabled button's left side padding is not > correct compared to the Policy Name Input box. > * On enabling the sidebar, the Recursive button is not aligned correctly > with the Enabled button. > > Creating this Improvement Jira for tracking these UI enhancements. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3249) Enhance RangerScriptExecutionContext class to provide APIs for comprehensive tag information
[ https://issues.apache.org/jira/browse/RANGER-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3249: - Fix Version/s: 2.2.0 3.0.0 > Enhance RangerScriptExecutionContext class to provide APIs for comprehensive > tag information > > > Key: RANGER-3249 > URL: https://issues.apache.org/jira/browse/RANGER-3249 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Use case: When an accessed resource is associated with multiple tags of the > same type but with different attribute values, current API to retrieve value > of an attribute incorrectly returns a scalar attribute value of any of the > associated tags. This may lead to incorrect access evaluation. The API needs > to return an array of values to caller. The caller then may decide how to use > the values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3254) sync source changes when same group is present in different sync source
[ https://issues.apache.org/jira/browse/RANGER-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3254: - Reporter: Deepesh Joshi (was: Sailaja Polavarapu) > sync source changes when same group is present in different sync source > --- > > Key: RANGER-3254 > URL: https://issues.apache.org/jira/browse/RANGER-3254 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Deepesh Joshi >Assignee: Sailaja Polavarapu >Priority: Major > > Test steps :- > 1. configure unix sync source. > 2. Add group "grp1" > 3. check sync source of group 'grp1'. it will be Unix. > 4. change sync source to LDAP, having "grp1" already present. > 5. restart user sync service. > 6. check sync source of group 'grp1'. it will be updated to "LDAP", Which is > not the accepted behaviour. > Ideally grp1 should not be synced as it is already present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3220) Zone name is not getting populated for tag based policy.
[ https://issues.apache.org/jira/browse/RANGER-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3220: - Fix Version/s: 2.2.0 3.0.0 > Zone name is not getting populated for tag based policy. > > > Key: RANGER-3220 > URL: https://issues.apache.org/jira/browse/RANGER-3220 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Zone name is not getting populated in access audit record even when the audit > record shows that a tag policy in a security zone made the access decision > when Ranger plugins are chained. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3218) User getting denied even after having tag based policy
[ https://issues.apache.org/jira/browse/RANGER-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3218: - Fix Version/s: 2.2.0 3.0.0 > User getting denied even after having tag based policy > -- > > Key: RANGER-3218 > URL: https://issues.apache.org/jira/browse/RANGER-3218 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Abhay Kulkarni >Assignee: Abhay Kulkarni >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Steps > 1.Created a database "vehicle1" with table "cars" and inserted some data into > table with hive user. > 2.Tried to access "vehicle1" with user 'unixuser1' which will be denied since > policy is not there. > select * from vehicle1.cars; > 3.Created a tag "tag1" in Atlas and assigned to database (vehicle1) > 4.Created a unzone policy for "tag1" in cm_tag and gave permission to > "unixuser1". > 5.Again tried to access the data with user 'unixuser1' but still it is > getting denied after having policy for the resource. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3207) Graceful handling of invalid usernames for usersync
[ https://issues.apache.org/jira/browse/RANGER-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3207: - Fix Version/s: 2.2.0 3.0.0 > Graceful handling of invalid usernames for usersync > --- > > Key: RANGER-3207 > URL: https://issues.apache.org/jira/browse/RANGER-3207 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Balazs Jeszenszky >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3207-Added-code-to-validate-user-and-group-na.patch > > > Currently, if there is an invalid username in a batch of users that usersync > tries to create in ranger admin, the entire batch of users will fail to > create. Usersync will then perpetually retry creating these users. This leads > to no alerts in Ranger, CM, or anywhere else besides usersync/admin logs, > both of which lack necessary details like the offending username. > In the current state, usersync is unusable if there is a single bad username > in the source database. > Usersync has to be more robust against malformed user names. IMO two ways > forward could be: > * (preferred) Allow partial failures, ie. create users that have well-formed > names even if a batch has a malformed user name, or > * Have a filter built into usersync that catches these before they reach > admin > Regardless of the solution, the error message should include the offending > username, and usersync should not keep trying to create users that are known > to cause failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3203) Add back the support to provide option to retrieve groups from user memberof attribute
[ https://issues.apache.org/jira/browse/RANGER-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3203: - Fix Version/s: 2.2.0 3.0.0 > Add back the support to provide option to retrieve groups from user memberof > attribute > -- > > Key: RANGER-3203 > URL: https://issues.apache.org/jira/browse/RANGER-3203 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3203-Added-back-support-to-allow-group-search.patch > > > As part of RANGER-2986, group search is made mandatory. This is breaking an > usecase to sync users and all the corresponding groups from AD/LDAP. > Previously, this could be achieved by setting > ranger.usersync.group.searchenabled to false and configure > ranger.usersync.ldap.user.groupnameattribute=memberof. That way, usersync > used to sync the users based on the user search base and user search filter > and use the "memberof" attribute of the user to sync all the groups each user > belongs to. > Now, if you want to achieve the same functionality, group search base and > group search filter have to be configured with appropriate filters for > sync'ing the groups which might be an extra configuration overhead. > This is same for both full sync and incremental sync. > Note:- When incremental sync is enabled, it is highly recommended to enable > group search and configure group search base and group search filter > accordingly. (Refer to RANGER-1211 for more details) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3207) Graceful handling of invalid usernames for usersync
[ https://issues.apache.org/jira/browse/RANGER-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3207: - Reporter: Balazs Jeszenszky (was: Sailaja Polavarapu) > Graceful handling of invalid usernames for usersync > --- > > Key: RANGER-3207 > URL: https://issues.apache.org/jira/browse/RANGER-3207 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Balazs Jeszenszky >Assignee: Sailaja Polavarapu >Priority: Major > > Currently, if there is an invalid username in a batch of users that usersync > tries to create in ranger admin, the entire batch of users will fail to > create. Usersync will then perpetually retry creating these users. This leads > to no alerts in Ranger, CM, or anywhere else besides usersync/admin logs, > both of which lack necessary details like the offending username. > In the current state, usersync is unusable if there is a single bad username > in the source database. > Usersync has to be more robust against malformed user names. IMO two ways > forward could be: > * (preferred) Allow partial failures, ie. create users that have well-formed > names even if a batch has a malformed user name, or > * Have a filter built into usersync that catches these before they reach > admin > Regardless of the solution, the error message should include the offending > username, and usersync should not keep trying to create users that are known > to cause failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3191) Ranger UI for configuring Audit filters.
[ https://issues.apache.org/jira/browse/RANGER-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3191: - Fix Version/s: 2.2.0 3.0.0 > Ranger UI for configuring Audit filters. > > > Key: RANGER-3191 > URL: https://issues.apache.org/jira/browse/RANGER-3191 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3191.patch, 0002-RANGER-3191.patch > > > Currently audit filter feature is implemented with the approach of json > strings directly being added in service config. This Jira is to track an > enhancement to this approach by adding Ranger UI option to configure audit > filters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3169) Ranger Usersync config for keystore type and truststore type for LDAPS are not effective
[ https://issues.apache.org/jira/browse/RANGER-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3169: - Fix Version/s: 2.2.0 3.0.0 > Ranger Usersync config for keystore type and truststore type for LDAPS are > not effective > > > Key: RANGER-3169 > URL: https://issues.apache.org/jira/browse/RANGER-3169 > Project: Ranger > Issue Type: Bug > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3169-Fixed-issue-where-we-are-not-reading-the.patch > > > Ranger Usersync configuration for keystore type and trusstore type values are > ignored and are always default to jceks. When FIPS is enabled, connecting to > LDAP with secure connection fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3205) Policy Item not render in report page.
[ https://issues.apache.org/jira/browse/RANGER-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3205: - Fix Version/s: 2.2.0 3.0.0 > Policy Item not render in report page. > -- > > Key: RANGER-3205 > URL: https://issues.apache.org/jira/browse/RANGER-3205 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Nitin Galave >Assignee: Nitin Galave >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3205.patch, reportPageError.png > > > In Report page policy items table not displaying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RANGER-3000) Audit-filter feature implementation to help reduce volume of audit logs generated
[ https://issues.apache.org/jira/browse/RANGER-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3000: - Fix Version/s: 2.2.0 > Audit-filter feature implementation to help reduce volume of audit logs > generated > - > > Key: RANGER-3000 > URL: https://issues.apache.org/jira/browse/RANGER-3000 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 2.2.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 2.2.0 > > > Audit-filter feature implementation to help reduce volume of audit logs > generated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3197) Is there any API which can tell which user has access to which resources
[ https://issues.apache.org/jira/browse/RANGER-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297512#comment-17297512 ] Velmurugan Periasamy commented on RANGER-3197: -- https://issues.apache.org/jira/browse/RANGER-2061 introduced a capability on the plugin side to retrieve user and group based Access Control Lists from Ranger policies for a given resource. Is this what you are looking for? CC [~abhayk] > Is there any API which can tell which user has access to which resources > > > Key: RANGER-3197 > URL: https://issues.apache.org/jira/browse/RANGER-3197 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Mudit Sharma >Priority: Major > > Is there any API available where given PLUGIN NAME, USER NAME and RESOURCE as > inputs, it can tell whether the access is granted or not, as per the entries > in DB. Also, this API can provide multiple combinations as well, like given > user and plugin name, list the resources and others > > Note: Policies might be outdated on individual plugin boxes but API can > provide just this info on the basis of policies in DB > > If the API is not available, would like to contribute on this if approved -- This message was sent by Atlassian Jira (v8.3.4#803005)