[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=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=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=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=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=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=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=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=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=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=desc=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 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=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=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
>
[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=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)
[jira] [Updated] (RANGER-3171) Ranger ui became broken after logout in Firefox
[ https://issues.apache.org/jira/browse/RANGER-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Velmurugan Periasamy updated RANGER-3171: - Fix Version/s: 2.2.0 3.0.0 > Ranger ui became broken after logout in Firefox > --- > > Key: RANGER-3171 > URL: https://issues.apache.org/jira/browse/RANGER-3171 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Mateen N Mansoori >Assignee: Dhaval Rajpara >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: 0001-RANGER-3171.patch > > > Steps to reproduce: > * open Firefox > * login to Ranger > * log out from Ranger (click Admin -> Log Out) > * open an protected url > Expected result: redirect to login page > Test result: ui is broken with errors in console log. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RANGER-3171) Ranger ui became broken after logout in Firefox
[ https://issues.apache.org/jira/browse/RANGER-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290046#comment-17290046 ] Velmurugan Periasamy commented on RANGER-3171: -- Patch committed master - https://gitbox.apache.org/repos/asf?p=ranger.git;a=commit;h=10c8555055579b34f18088a26949eb1254c0e914 ranger-2.2 - https://gitbox.apache.org/repos/asf?p=ranger.git;a=commit;h=ede568667973c96b1be5dcba8117c18725a98f58 > Ranger ui became broken after logout in Firefox > --- > > Key: RANGER-3171 > URL: https://issues.apache.org/jira/browse/RANGER-3171 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Mateen N Mansoori >Assignee: Dhaval Rajpara >Priority: Major > Attachments: 0001-RANGER-3171.patch > > > Steps to reproduce: > * open Firefox > * login to Ranger > * log out from Ranger (click Admin -> Log Out) > * open an protected url > Expected result: redirect to login page > Test result: ui is broken with errors in console log. -- This message was sent by Atlassian Jira (v8.3.4#803005)
