Re: Review Request 74122: RANGER-3914: Change sync_source column's datatype from varchar to text

[Pradeep Agrawal]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74122/
---

(Updated Sept. 21, 2022, 6:53 a.m.)


Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Nikhil P, Pradeep 
Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Changes
---

Tested the patch for mssql db flavor.


Bugs: RANGER-3914
https://issues.apache.org/jira/browse/RANGER-3914


Repository: ranger


Description
---

**Problem Statement:**
Ranger install or upgrade may fail with below error when mysql engine having 
database charset set to utfmb4.

com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
Row size too large. The maximum row size for the used table type, not counting 
BLOBs, is 65535. 
This includes storage overhead, check the manual. You have to change some 
columns to TEXT or BLOBs

SQLException : SQL state: 42000 
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Row size too large. 
The maximum row size for the used table type, not counting BLOBs, is 65535. 
This includes storage overhead, check the manual. You have to change some 
columns to TEXT or BLOBs ErrorCode: 1118

**Proposed solution:**
Since BLOBs are not counted in the calculation of row size we can change 
sync_source column type to Blob/text/clob type.


Diffs (updated)
-

  security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 309c4196b 
  
security-admin/db/mysql/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
 a23976b80 
  
security-admin/db/mysql/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
 5a40a89e0 
  
security-admin/db/mysql/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
 PRE-CREATION 
  security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
1af0a04ac 
  
security-admin/db/oracle/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
 3fc4b975d 
  
security-admin/db/oracle/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
 ed8dbaf7f 
  
security-admin/db/oracle/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
 PRE-CREATION 
  security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
baa6288d2 
  
security-admin/db/postgres/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
 b1e8c3845 
  
security-admin/db/postgres/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
 68117a123 
  
security-admin/db/postgres/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
 PRE-CREATION 
  
security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql 
5e8070ba2 
  
security-admin/db/sqlanywhere/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
 38a85e97b 
  
security-admin/db/sqlanywhere/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
 335459058 
  
security-admin/db/sqlanywhere/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
 PRE-CREATION 
  security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
8b5833eae 
  
security-admin/db/sqlserver/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
 ae216445b 
  
security-admin/db/sqlserver/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
 3b8a8d83a 
  
security-admin/db/sqlserver/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
 PRE-CREATION 


Diff: https://reviews.apache.org/r/74122/diff/4/

Changes: https://reviews.apache.org/r/74122/diff/3-4/


Testing
---

Tested Ranger install and upgrade with this patch which was failing earlier.


Thanks,

Pradeep Agrawal

[jira] [Commented] (RANGER-2572) Unable to update/add user to group with userName using rest API.

[Ramachandran (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607549#comment-17607549
 ] 

Ramachandran commented on RANGER-2572:
--

We have a requirement to add/update/delete a user to a group in ranger through 
rest API. I see that there are rest API available using the userId but not 
through userName — I will take this task for the below rest API's

/api/roles/name/\{name}/addUsersAndGroups

/api/roles/\{id}/removeUsersAndGroups

/api/roles/\{id}/removeAdminFromUsersAndGroups

and add the new APIs which support for roleName instead of rolled

/api/roles/name/\{name}/addUsersAndGroups

/api/roles//name/\{name}/removeUsersAndGroups

/api/roles/name/\{name}/removeAdminFromUsersAndGroups

cc >> [~madhan]  [~pradeep] 

 

 

> Unable to update/add user to group with userName using rest API.
> 
>
> Key: RANGER-2572
> URL: https://issues.apache.org/jira/browse/RANGER-2572
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Affects Versions: 1.2.0
>Reporter: bharath
>Priority: Critical
>  Labels: features
>
> Hi Team,
>  # We have a requirement to add/update/delete a user to a group in ranger 
> through rest API. I see that there are rest API available using the userId 
> but not through userName.  Is there any way we can do this ??
>  # Also while creating a user the id that is given in JSON request is not 
> taken, instead ranger creates its own id for the user and gives it back as a 
> response. Is there a way to force ranger the id that I provide. But even this 
> id is not seen anywhere in the ranger UI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (RANGER-2572) Unable to update/add user to group with userName using rest API.

[Ramachandran (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramachandran reassigned RANGER-2572:


Assignee: Ramachandran

> Unable to update/add user to group with userName using rest API.
> 
>
> Key: RANGER-2572
> URL: https://issues.apache.org/jira/browse/RANGER-2572
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Affects Versions: 1.2.0
>Reporter: bharath
>Assignee: Ramachandran
>Priority: Critical
>  Labels: features
>
> Hi Team,
>  # We have a requirement to add/update/delete a user to a group in ranger 
> through rest API. I see that there are rest API available using the userId 
> but not through userName.  Is there any way we can do this ??
>  # Also while creating a user the id that is given in JSON request is not 
> taken, instead ranger creates its own id for the user and gives it back as a 
> response. Is there a way to force ranger the id that I provide. But even this 
> id is not seen anywhere in the ranger UI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74122: RANGER-3914: Change sync_source column's datatype from varchar to text

[Pradeep Agrawal]

> On Sept. 20, 2022, 7:45 a.m., Kirby Zhou wrote:
> > security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql
> > Line 371 (original), 371 (patched)
> > 
> >
> > Why do not change this to text?
> > There are a lot of VARCHAR(4000) / VARCHAR2(4000) left unchanged.

They are not creating the issue for which the patch has been raised for. 
Also changing all of them will take extra time during the upgrade when user is 
having lot of data.
If you are facing any issue with that please create a separate jira and provide 
all details.


- Pradeep


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74122/#review224683
---


On Sept. 16, 2022, 6:12 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74122/
> ---
> 
> (Updated Sept. 16, 2022, 6:12 a.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Nikhil P, 
> Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja Polavarapu, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3914
> https://issues.apache.org/jira/browse/RANGER-3914
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:**
> Ranger install or upgrade may fail with below error when mysql engine having 
> database charset set to utfmb4.
> 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
> Row size too large. The maximum row size for the used table type, not 
> counting BLOBs, is 65535. 
> This includes storage overhead, check the manual. You have to change some 
> columns to TEXT or BLOBs
> 
> SQLException : SQL state: 42000 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Row size too 
> large. The maximum row size for the used table type, not counting BLOBs, is 
> 65535. This includes storage overhead, check the manual. You have to change 
> some columns to TEXT or BLOBs ErrorCode: 1118
> 
> **Proposed solution:**
> Since BLOBs are not counted in the calculation of row size we can change 
> sync_source column type to Blob/text/clob type.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 309c4196b 
>   
> security-admin/db/mysql/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  a23976b80 
>   
> security-admin/db/mysql/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  5a40a89e0 
>   
> security-admin/db/mysql/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> 1af0a04ac 
>   
> security-admin/db/oracle/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  3fc4b975d 
>   
> security-admin/db/oracle/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  ed8dbaf7f 
>   
> security-admin/db/oracle/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> baa6288d2 
>   
> security-admin/db/postgres/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  b1e8c3845 
>   
> security-admin/db/postgres/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  68117a123 
>   
> security-admin/db/postgres/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  5e8070ba2 
>   
> security-admin/db/sqlanywhere/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  38a85e97b 
>   
> security-admin/db/sqlanywhere/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  335459058 
>   
> security-admin/db/sqlanywhere/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> 8b5833eae 
>   
> security-admin/db/sqlserver/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  ae216445b 
>   
> security-admin/db/sqlserver/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  3b8a8d83a 
>   
> security-admin/db/sqlserver/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/74122/diff/3/
> 
> 
> Testing
> ---
> 
> Tested Ranger install and upgrade with this patch which was failing earlier.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>

[jira] [Commented] (RANGER-3924) Incrementing timestamp value for group and user is not 1sec but 60ms. It should be 1sec.

[YUBI LEE (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607452#comment-17607452
 ] 

YUBI LEE commented on RANGER-3924:
--

Review is available here - https://reviews.apache.org/r/74132/

> Incrementing timestamp value for group and user is not 1sec but 60ms. It 
> should be 1sec.
> 
>
> Key: RANGER-3924
> URL: https://issues.apache.org/jira/browse/RANGER-3924
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.3.0
>Reporter: YUBI LEE
>Priority: Major
> Attachments: 
> 0001-RANGER-3924-Incrementing-timestamp-value-for-group-a.patch
>
>
> As RANGER-1852 
> (https://github.com/apache/ranger/commit/38141722ee791f8ae0006247af148ed0bfa7db0c),
>  incrementing timestamp value has become from 60s to 60ms.
> However, it should be 1 sec. Maybe it is a mistake.
> And the wrong value is inherited to LdapUserGroupBuilder.java with 
> RANGER-2986 
> (https://github.com/apache/ranger/commit/4610df1fd126a07f1e19c5bed53e50742bb9f428#diff-5e58a9fb4de31652ab3ede63673d4b0ec614d540831027f02417612f36d7ae73R364-R373).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74132: RANGER-3924: Incrementing timestamp value for group and user is not 1sec but 60ms. It should be 1sec.

[Yubi Lee]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74132/
---

Review request for ranger.


Bugs: RANGER-3924
https://issues.apache.org/jira/browse/RANGER-3924


Repository: ranger


Description
---

As RANGER-1852 
(https://github.com/apache/ranger/commit/38141722ee791f8ae0006247af148ed0bfa7db0c),
 incrementing timestamp value has become from 60s to 60ms.
However, it should be 1 sec. Maybe it is a mistake.

And the wrong value is inherited to LdapUserGroupBuilder.java with RANGER-2986 
(https://github.com/apache/ranger/commit/4610df1fd126a07f1e19c5bed53e50742bb9f428#diff-5e58a9fb4de31652ab3ede63673d4b0ec614d540831027f02417612f36d7ae73R364-R373).


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 b1a6af183 


Diff: https://reviews.apache.org/r/74132/diff/1/


Testing
---


Thanks,

Yubi Lee

[jira] [Updated] (RANGER-3924) Incrementing timestamp value for group and user is not 1sec but 60ms. It should be 1sec.

[YUBI LEE (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YUBI LEE updated RANGER-3924:
-
Attachment: 0001-RANGER-3924-Incrementing-timestamp-value-for-group-a.patch

> Incrementing timestamp value for group and user is not 1sec but 60ms. It 
> should be 1sec.
> 
>
> Key: RANGER-3924
> URL: https://issues.apache.org/jira/browse/RANGER-3924
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.3.0
>Reporter: YUBI LEE
>Priority: Major
> Attachments: 
> 0001-RANGER-3924-Incrementing-timestamp-value-for-group-a.patch
>
>
> As RANGER-1852 
> (https://github.com/apache/ranger/commit/38141722ee791f8ae0006247af148ed0bfa7db0c),
>  incrementing timestamp value has become from 60s to 60ms.
> However, it should be 1 sec. Maybe it is a mistake.
> And the wrong value is inherited to LdapUserGroupBuilder.java with 
> RANGER-2986 
> (https://github.com/apache/ranger/commit/4610df1fd126a07f1e19c5bed53e50742bb9f428#diff-5e58a9fb4de31652ab3ede63673d4b0ec614d540831027f02417612f36d7ae73R364-R373).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3924) Incrementing timestamp value for group and user is not 1sec but 60ms. It should be 1sec.

[YUBI LEE (Jira)]

YUBI LEE created RANGER-3924:


 Summary: Incrementing timestamp value for group and user is not 
1sec but 60ms. It should be 1sec.
 Key: RANGER-3924
 URL: https://issues.apache.org/jira/browse/RANGER-3924
 Project: Ranger
  Issue Type: Bug
  Components: usersync
Affects Versions: 2.3.0
Reporter: YUBI LEE


As RANGER-1852 
(https://github.com/apache/ranger/commit/38141722ee791f8ae0006247af148ed0bfa7db0c),
 incrementing timestamp value has become from 60s to 60ms.
However, it should be 1 sec. Maybe it is a mistake.

And the wrong value is inherited to LdapUserGroupBuilder.java with RANGER-2986 
(https://github.com/apache/ranger/commit/4610df1fd126a07f1e19c5bed53e50742bb9f428#diff-5e58a9fb4de31652ab3ede63673d4b0ec614d540831027f02417612f36d7ae73R364-R373).




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [ranger] eubnara closed pull request #170: RANGER-3858: On dev-support, service creation and ranger-kafka-plugin setup are failed

[GitBox]

eubnara closed pull request #170: RANGER-3858: On dev-support, service creation 
and ranger-kafka-plugin setup are failed
URL: https://github.com/apache/ranger/pull/170


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@ranger.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [ranger] eubnara commented on pull request #170: RANGER-3858: On dev-support, service creation and ranger-kafka-plugin setup are failed

[GitBox]

eubnara commented on PR #170:
URL: https://github.com/apache/ranger/pull/170#issuecomment-1253060014

   resolved at 
https://github.com/apache/ranger/commit/e7cd999f09139c8bb973e138b7cae487f5d33327


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@ranger.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (RANGER-3923) Dataset policies

[Madhan Neethiraj (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3923:
-
Description: 
Given the primary business value of Apache Ranger is to enable sharing of 
resources, it will help if Apache Ranger provides an abstraction that enables a 
set of resources/data across services, a dataset, to be the unit of sharing 
instead of one or more resources in each service. This has several benefits, 
like:
 # A single policy to manage access to data in multiple services - like HBase, 
Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, ADLS-Gen2. This 
enables authorization to be centered around a purpose, like:
 ** Marketing Campaign 2022 dataset
 ** Sales 2021 dataset
 ** CA Claims 2021 dataset
 # Enables different set of users to manage sharing data into a dataset and 
manage access to the data in a dataset:
 ** Data owners share data into a dataset, with necessary masking,  row-filters 
and schedules; they can update the share details, including stop sharing into a 
dataset.
 ** Dataset admins manage who has access to the data in the dataset. This 
relieves data owners from having to micromanage access to the shared data, for 
example when a user needs access to the data in multiple services to 
participate in a project.

Attached document has more details on this new abstraction, including a number 
of questions & answers that to help understand various aspects of this feature. 
Please read and add your comments/suggestions.

  was:
Given the primary business value of Apache Ranger is to enable sharing of 
resources, it will help if Apache Ranger provides an abstraction that enables a 
set of resources/data across services, a dataset, to be the unit of sharing 
instead of one or more resources in each service. This has several benefits, 
like:
 * A single policy to manage access to data in multiple services - like HBase, 
Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, ADLS-Gen2. This 
enables authorization to be centered around a purpose, like:
 * 
 ** Marketing Campaign 2022 dataset
 ** Sales 2021 dataset
 ** CA Claims 2021 dataset
 * Enables different set of users to manage sharing data into a dataset and 
manage access to the data in a dataset:
 * 
 ** Data owners share data into a dataset, with necessary masking,  row-filters 
and schedules; they can update the share details, including stop sharing into a 
dataset.
 ** Dataset admins manage who has access to the data in the dataset. This 
relieves data owners from having to micromanage access to the shared data, for 
example when a user needs access to the data in multiple services to 
participate in a project.

Attached document has more details on this new abstraction, including a number 
of questions & answers that to help understand various aspects of this feature. 
Please read and add your comments/suggestions.


> Dataset policies
> 
>
> Key: RANGER-3923
> URL: https://issues.apache.org/jira/browse/RANGER-3923
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: Apache Ranger - Dataset.pdf
>
>
> Given the primary business value of Apache Ranger is to enable sharing of 
> resources, it will help if Apache Ranger provides an abstraction that enables 
> a set of resources/data across services, a dataset, to be the unit of sharing 
> instead of one or more resources in each service. This has several benefits, 
> like:
>  # A single policy to manage access to data in multiple services - like 
> HBase, Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, 
> ADLS-Gen2. This enables authorization to be centered around a purpose, like:
>  ** Marketing Campaign 2022 dataset
>  ** Sales 2021 dataset
>  ** CA Claims 2021 dataset
>  # Enables different set of users to manage sharing data into a dataset and 
> manage access to the data in a dataset:
>  ** Data owners share data into a dataset, with necessary masking,  
> row-filters and schedules; they can update the share details, including stop 
> sharing into a dataset.
>  ** Dataset admins manage who has access to the data in the dataset. This 
> relieves data owners from having to micromanage access to the shared data, 
> for example when a user needs access to the data in multiple services to 
> participate in a project.
> Attached document has more details on this new abstraction, including a 
> number of questions & answers that to help understand various aspects of this 
> feature. Please read and add your comments/suggestions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-3923) Dataset policies

[Madhan Neethiraj (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3923:
-
Description: 
Given the primary business value of Apache Ranger is to enable sharing of 
resources, it will help if Apache Ranger provides an abstraction that enables a 
set of resources/data across services, a dataset, to be the unit of sharing 
instead of one or more resources in each service. This has several benefits, 
like:
 * A single policy to manage access to data in multiple services - like HBase, 
Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, ADLS-Gen2. This 
enables authorization to be centered around a purpose, like:
 * 
 ** Marketing Campaign 2022 dataset
 ** Sales 2021 dataset
 ** CA Claims 2021 dataset
 * Enables different set of users to manage sharing data into a dataset and 
manage access to the data in a dataset:
 * 
 ** Data owners share data into a dataset, with necessary masking,  row-filters 
and schedules; they can update the share details, including stop sharing into a 
dataset.
 ** Dataset admins manage who has access to the data in the dataset. This 
relieves data owners from having to micromanage access to the shared data, for 
example when a user needs access to the data in multiple services to 
participate in a project.

Attached document has more details on this new abstraction, including a number 
of questions & answers that to help understand various aspects of this feature. 
Please read and add your comments/suggestions.

  was:
Given the primary business value of Apache Ranger is to enable sharing of 
resources, it will help if Apache Ranger provides an abstraction that enables a 
set of resources/data across services, a dataset, to be the unit of sharing 
instead of one or more resources in each service. This has several benefits, 
like:
 # A single policy to manage access to data in multiple services - like HBase, 
Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, ADLS-Gen2. This 
enables authorization to be centered around a purpose, like:
 * Marketing Campaign 2022 dataset
 * Sales 2021 dataset
 * CA Claims 2021 dataset


 # Enables different set of users to manage sharing data into a dataset and 
manage access to the data in a dataset:
 * Data owners share data into a dataset, with necessary masking,  row-filters 
and schedules; they can update the share details, including stop sharing into a 
dataset.
 * Dataset admins manage who has access to the data in the dataset. This 
relieves data owners from having to micromanage access to the shared data, for 
example when a user needs access to the data in multiple services to 
participate in a project.


Attached document has more details on this new abstraction, including a number 
of questions & answers that to help understand various aspects of this feature. 
Please read and add your comments/suggestions.


> Dataset policies
> 
>
> Key: RANGER-3923
> URL: https://issues.apache.org/jira/browse/RANGER-3923
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: Apache Ranger - Dataset.pdf
>
>
> Given the primary business value of Apache Ranger is to enable sharing of 
> resources, it will help if Apache Ranger provides an abstraction that enables 
> a set of resources/data across services, a dataset, to be the unit of sharing 
> instead of one or more resources in each service. This has several benefits, 
> like:
>  * A single policy to manage access to data in multiple services - like 
> HBase, Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, 
> ADLS-Gen2. This enables authorization to be centered around a purpose, like:
>  * 
>  ** Marketing Campaign 2022 dataset
>  ** Sales 2021 dataset
>  ** CA Claims 2021 dataset
>  * Enables different set of users to manage sharing data into a dataset and 
> manage access to the data in a dataset:
>  * 
>  ** Data owners share data into a dataset, with necessary masking,  
> row-filters and schedules; they can update the share details, including stop 
> sharing into a dataset.
>  ** Dataset admins manage who has access to the data in the dataset. This 
> relieves data owners from having to micromanage access to the shared data, 
> for example when a user needs access to the data in multiple services to 
> participate in a project.
> Attached document has more details on this new abstraction, including a 
> number of questions & answers that to help understand various aspects of this 
> feature. Please read and add your comments/suggestions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-3923) Dataset policies

[Madhan Neethiraj (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3923:
-
Attachment: Apache Ranger - Dataset.pdf

> Dataset policies
> 
>
> Key: RANGER-3923
> URL: https://issues.apache.org/jira/browse/RANGER-3923
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: Apache Ranger - Dataset.pdf
>
>
> Given the primary business value of Apache Ranger is to enable sharing of 
> resources, it will help if Apache Ranger provides an abstraction that enables 
> a set of resources/data across services, a dataset, to be the unit of sharing 
> instead of one or more resources in each service. This has several benefits, 
> like:
>  # A single policy to manage access to data in multiple services - like 
> HBase, Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, 
> ADLS-Gen2. This enables authorization to be centered around a purpose, like:
>  * Marketing Campaign 2022 dataset
>  * Sales 2021 dataset
>  * CA Claims 2021 dataset
>  # Enables different set of users to manage sharing data into a dataset and 
> manage access to the data in a dataset:
>  * Data owners share data into a dataset, with necessary masking,  
> row-filters and schedules; they can update the share details, including stop 
> sharing into a dataset.
>  * Dataset admins manage who has access to the data in the dataset. This 
> relieves data owners from having to micromanage access to the shared data, 
> for example when a user needs access to the data in multiple services to 
> participate in a project.
> Attached document has more details on this new abstraction, including a 
> number of questions & answers that to help understand various aspects of this 
> feature. Please read and add your comments/suggestions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3923) Dataset policies

[Madhan Neethiraj (Jira)]

Madhan Neethiraj created RANGER-3923:


 Summary: Dataset policies
 Key: RANGER-3923
 URL: https://issues.apache.org/jira/browse/RANGER-3923
 Project: Ranger
  Issue Type: New Feature
  Components: Ranger
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Given the primary business value of Apache Ranger is to enable sharing of 
resources, it will help if Apache Ranger provides an abstraction that enables a 
set of resources/data across services, a dataset, to be the unit of sharing 
instead of one or more resources in each service. This has several benefits, 
like:
 # A single policy to manage access to data in multiple services - like HBase, 
Hive, Snowflake, Kafka, Google BigQuery, AWS S3, AWS Redshift, ADLS-Gen2. This 
enables authorization to be centered around a purpose, like:
 * Marketing Campaign 2022 dataset
 * Sales 2021 dataset
 * CA Claims 2021 dataset


 # Enables different set of users to manage sharing data into a dataset and 
manage access to the data in a dataset:
 * Data owners share data into a dataset, with necessary masking,  row-filters 
and schedules; they can update the share details, including stop sharing into a 
dataset.
 * Dataset admins manage who has access to the data in the dataset. This 
relieves data owners from having to micromanage access to the shared data, for 
example when a user needs access to the data in multiple services to 
participate in a project.


Attached document has more details on this new abstraction, including a number 
of questions & answers that to help understand various aspects of this feature. 
Please read and add your comments/suggestions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3922) Ranger build has missing dependencies when calling credentialapi.buildks create

[Neil Joshi (Jira)]

Neil Joshi created RANGER-3922:
--

 Summary: Ranger build has missing dependencies when calling  
credentialapi.buildks create
 Key: RANGER-3922
 URL: https://issues.apache.org/jira/browse/RANGER-3922
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Neil Joshi


Ranger 2.3.0 has build issues with missing dependencies when calling:
{code:java}
org.apache.ranger.credentalapi.buildks create{code}
missing -
 # org/apache/commons/lang3/StringUtils
 # org/apache/commons/compress/archivers/tar/TarArchiver

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-3775) Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramachandran updated RANGER-3775:
-
Attachment: 0001-RANGER-3775-Logback.xml-has-been-incorrectly-modifie.patch

> Logback.xml has been incorrectly modified by RANGER-3704.
> -
>
> Key: RANGER-3775
> URL: https://issues.apache.org/jira/browse/RANGER-3775
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: kirby zhou
>Priority: Critical
> Attachments: 
> 0001-RANGER-3775-Logback.xml-has-been-incorrectly-modifie.patch
>
>
> {code:java}
> git show 361f179249 | filterdiff -i '*/logback.xml'
> diff --git a/security-admin/src/main/webapp/WEB-INF/logback.xml 
> b/security-admin/src/main/webapp/WEB-INF/logback.xml
> index 997f3bc59..53cdc49cf 100644
> --- a/security-admin/src/main/webapp/WEB-INF/logback.xml
> +++ b/security-admin/src/main/webapp/WEB-INF/logback.xml
> @@ -80,7 +80,7 @@
>    
>      
>    
> -  
> +  
>      
>    
>     
> {code}
> These changes seems not related to the issue RANGER-3704.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (RANGER-3775) Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramachandran reassigned RANGER-3775:


Assignee: Ramachandran

> Logback.xml has been incorrectly modified by RANGER-3704.
> -
>
> Key: RANGER-3775
> URL: https://issues.apache.org/jira/browse/RANGER-3775
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: kirby zhou
>Assignee: Ramachandran
>Priority: Critical
> Attachments: 
> 0001-RANGER-3775-Logback.xml-has-been-incorrectly-modifie.patch
>
>
> {code:java}
> git show 361f179249 | filterdiff -i '*/logback.xml'
> diff --git a/security-admin/src/main/webapp/WEB-INF/logback.xml 
> b/security-admin/src/main/webapp/WEB-INF/logback.xml
> index 997f3bc59..53cdc49cf 100644
> --- a/security-admin/src/main/webapp/WEB-INF/logback.xml
> +++ b/security-admin/src/main/webapp/WEB-INF/logback.xml
> @@ -80,7 +80,7 @@
>    
>      
>    
> -  
> +  
>      
>    
>     
> {code}
> These changes seems not related to the issue RANGER-3704.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RANGER-3775) Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607357#comment-17607357
 ] 

Ramachandran commented on RANGER-3775:
--

[~kirbyzhou] The review is available 
here:[https://reviews.apache.org/r/74131.|https://reviews.apache.org/r/74131]

cc >> [~madhan] 

> Logback.xml has been incorrectly modified by RANGER-3704.
> -
>
> Key: RANGER-3775
> URL: https://issues.apache.org/jira/browse/RANGER-3775
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: kirby zhou
>Priority: Critical
>
> {code:java}
> git show 361f179249 | filterdiff -i '*/logback.xml'
> diff --git a/security-admin/src/main/webapp/WEB-INF/logback.xml 
> b/security-admin/src/main/webapp/WEB-INF/logback.xml
> index 997f3bc59..53cdc49cf 100644
> --- a/security-admin/src/main/webapp/WEB-INF/logback.xml
> +++ b/security-admin/src/main/webapp/WEB-INF/logback.xml
> @@ -80,7 +80,7 @@
>    
>      
>    
> -  
> +  
>      
>    
>     
> {code}
> These changes seems not related to the issue RANGER-3704.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74131: Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran Krishnan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74131/
---

Review request for ranger, Madhan Neethiraj and Pradeep Agrawal.


Bugs: RANGER-3775
https://issues.apache.org/jira/browse/RANGER-3775


Repository: ranger


Description
---

{logger name="com.mchange"}
is used by c3p0 and {logger name="jdbc.connection"}

is used by log4jdbc


  

  



  


Diffs
-

  security-admin/src/main/resources/conf.dist/logback.xml 53cdc49cf 


Diff: https://reviews.apache.org/r/74131/diff/1/


Testing
---


Thanks,

Ramachandran Krishnan

Re: Review Request 74129: RANGER-3920 When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing

[Madhan Neethiraj]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74129/#review224687
---


Ship it!




Ship It!

- Madhan Neethiraj


On Sept. 20, 2022, 11:05 a.m., Ankita Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74129/
> ---
> 
> (Updated Sept. 20, 2022, 11:05 a.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Mehul Parikh, Monika Kachhadiya, 
> Pradeep Agrawal, Siddhesh Phatak, Sailaja Polavarapu, and Subhrat Chaudhary.
> 
> 
> Bugs: RANGER-3920
> https://issues.apache.org/jira/browse/RANGER-3920
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Problem Statement:
> =
> Currently, Usersync sync's users/groups/usergroup in batches. In doing so, 
> the user/group/usergroup at the end of the batch is not sync'ed. 
> For example consider batch is of size 1000, so batch starts from 0-999 and  
> then  next batch starts from 1001-1999. So in each batch one 
> user/group/usergroup is missing.
> 
> Solution:
> 
> Updated code to handle this missing one user in each batch.
> 
> 
> Diffs
> -
> 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
>  654b83282 
> 
> 
> Diff: https://reviews.apache.org/r/74129/diff/1/
> 
> 
> Testing
> ---
> 
> Tested with large number user/group/usergroup membership if all the 
> user/group/usergroup membership is getting sync'ed in Ranger admin
> 
> 
> Thanks,
> 
> Ankita Sinha
> 
>

[jira] [Commented] (RANGER-3920) When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing

[Sailaja Polavarapu (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607239#comment-17607239
 ] 

Sailaja Polavarapu commented on RANGER-3920:


Hi [~ankita] , This might be duplicate for RANGER-3469. Can you please check 
the below review request and may be merge both if needed?

https://reviews.apache.org/r/73677/

> When sync'ing users from Ldap,  intermittent User/Group/UserGroup membership  
> is missing
> 
>
> Key: RANGER-3920
> URL: https://issues.apache.org/jira/browse/RANGER-3920
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger, usersync
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
>Priority: Major
> Fix For: 2.4.0
>
>
> Problem Statement:
> Currently, Usersync sync's users/groups/usergroup in batches. In doing so, 
> the user/group/usergroup at the end of the batch is not sync'ed. 
> For example consider batch is of size 1000, so batch starts from 0-999 and  
> then  next batch starts from 1001-1999. So in each batch one 
> user/group/usergroup is missing.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [ranger] Sangrho opened a new pull request, #176: For solving the issue when run setup.sh about x_portal_user table

[GitBox]

Sangrho opened a new pull request, #176:
URL: https://github.com/apache/ranger/pull/176

   ```
   ERROR 1118 (42000): Row size too large. The maximum row size for the used 
table type, not counting BLOBs, is 65535. This includes storage overhead, check 
the manual. You have to change some columns to TEXT or BLOBs
   ```
   If I solve this issue, I should change 'innodb_page_size' but it is hard to 
us. So I change the type of those columns to TEXT


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@ranger.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.

[kirby zhou (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

kirby zhou updated RANGER-3921:
---
Description: 
In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,

we have hive policy:
{code:java}
{"id":8,"name":"db=dummy; table=*; 
column=*","isEnabled":true,"isAuditEnabled":true,
"resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
"policyItems":[
{"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
],
"allowExceptions":[
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
]
} {code}
According to the general understanding, this is given the permission of column 
level, rather than the permission of table level or database level.

 

But these 2 new test case can pass:
{code:java}
{"name":"ALLOW 'drop dummy/*;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy", "table": "dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy/dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
}
,
{"name":"ALLOW 'drop dummy;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
} ,
{"name":"ALLOW 'drop dummy/udf=dummy;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy", "udf":"dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy for user1"
  },
  "result":{"isAudited":false,"isAllowed":true,"policyId":8}
} {code}
 

This doesn't seem reasonable. A user who can not drop UDF, but can drop whole 
database.

 

Or can someone tell me how to only give users column-level permissions without 
involving table or database?

 

 

 

 

 

 

  was:
In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,

we have hive policy:
{code:java}
{"id":8,"name":"db=dummy; table=*; 
column=*","isEnabled":true,"isAuditEnabled":true,
"resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
"policyItems":[
{"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
],
"allowExceptions":[
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
]
} {code}
According to the general understanding, this is given the permission of column 
level, rather than the permission of table level or database level.

 

But these 2 new test case can pass:
{code:java}
{"name":"ALLOW 'drop dummy/*;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy", "table": "dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy/dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
}
,
{"name":"ALLOW 'drop dummy;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
}
 {code}
 

This doesn't seem reasonable.

Or can someone tell me how to only give users column-level permissions without 
involving table or database?

 

 

 

 

 

 


> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and 
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*; 
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{

[jira] [Updated] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and database.

[kirby zhou (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

kirby zhou updated RANGER-3921:
---
Summary: User with DROP ACL on "db=dummy; table=*; column=*" can do drop 
table and database.  (was: User with DROP ACL on "db=dummy; table=*; column=*" 
can do drop table.)

> User with DROP ACL on "db=dummy; table=*; column=*" can do drop table and 
> database.
> ---
>
> Key: RANGER-3921
> URL: https://issues.apache.org/jira/browse/RANGER-3921
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 3.0.0, 2.3.0, 2.4.0
>Reporter: kirby zhou
>Priority: Major
>
> In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,
> we have hive policy:
> {code:java}
> {"id":8,"name":"db=dummy; table=*; 
> column=*","isEnabled":true,"isAuditEnabled":true,
> "resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
> "policyItems":[
> {"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
> ],
> "allowExceptions":[
> {"accesses":[{"type":"create","isAllowed":true}, 
> {"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
> {"accesses":[{"type":"create","isAllowed":true}, 
> {"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
> ]
> } {code}
> According to the general understanding, this is given the permission of 
> column level, rather than the permission of table level or database level.
>  
> But these 2 new test case can pass:
> {code:java}
> {"name":"ALLOW 'drop dummy/*;' for user1",
>   "request":{
> "resource":{"elements":{"database":"dummy", "table": "dummy"}},
> 
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
> dummy/dummy for user1"
>   },
>   "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
> ,
> {"name":"ALLOW 'drop dummy;' for user1",
>   "request":{
> "resource":{"elements":{"database":"dummy"}},
> 
> "accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
> dummy for user1"
>   },
>   "result":{"isAudited":true,"isAllowed":true,"policyId":8}
> }
>  {code}
>  
> This doesn't seem reasonable.
> Or can someone tell me how to only give users column-level permissions 
> without involving table or database?
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3921) User with DROP ACL on "db=dummy; table=*; column=*" can do drop table.

[kirby zhou (Jira)]

kirby zhou created RANGER-3921:
--

 Summary: User with DROP ACL on "db=dummy; table=*; column=*" can 
do drop table.
 Key: RANGER-3921
 URL: https://issues.apache.org/jira/browse/RANGER-3921
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Affects Versions: 2.3.0, 3.0.0, 2.4.0
Reporter: kirby zhou


In agents-common/src/test/resources/policyengine/test_policyengine_hive.json,

we have hive policy:
{code:java}
{"id":8,"name":"db=dummy; table=*; 
column=*","isEnabled":true,"isAuditEnabled":true,
"resources":{"database":{"values":["dummy"]},"table":{"values":["*"]},"column":{"values":["*"]}},
"policyItems":[
{"accesses":[{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user1","user2"],"groups":[],"delegateAdmin":false}
],
"allowExceptions":[
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true}],"users":["user1"],"groups":[],"delegateAdmin":false},
{"accesses":[{"type":"create","isAllowed":true}, 
{"type":"update","isAllowed":true},{"type":"drop","isAllowed":true}],"users":["user2"],"groups":[],"delegateAdmin":false}
]
} {code}
According to the general understanding, this is given the permission of column 
level, rather than the permission of table level or database level.

 

But these 2 new test case can pass:
{code:java}
{"name":"ALLOW 'drop dummy/*;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy", "table": "dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy/dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
}
,
{"name":"ALLOW 'drop dummy;' for user1",
  "request":{
"resource":{"elements":{"database":"dummy"}},

"accessType":"drop","user":"user1","userGroups":["users"],"requestData":"drop 
dummy for user1"
  },
  "result":{"isAudited":true,"isAllowed":true,"policyId":8}
}
 {code}
 

This doesn't seem reasonable.

Or can someone tell me how to only give users column-level permissions without 
involving table or database?

 

 

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74123: RANGER-3916 : Ranger UI fails to open when the Ranger admin domain name includes "service" keyword in it.

[Dineshkumar Yadav]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74123/
---

(Updated Sept. 20, 2022, 11:46 a.m.)


Review request for ranger, Jayendra Parab, Kishor Gollapalliwar, Abhay 
Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, and Velmurugan 
Periasamy.


Bugs: RANGER-3916
https://issues.apache.org/jira/browse/RANGER-3916


Repository: ranger


Description
---

When domain name itself contain "service" keyword in it then it leads to error 
message. 
eg. when we try http://domain_name_with_service:6080/  as this has keyword 
"service" as part of url. it gives below error instead of redirecting to 
"http://domain_name_with_service:6080/login.jsp";.
{"statusCode":401,"msgDesc":"Authentication Failed"}


Diffs
-

  
security-admin/src/main/java/org/apache/ranger/security/web/authentication/RangerAuthenticationEntryPoint.java
 26786b9eb 


Diff: https://reviews.apache.org/r/74123/diff/1/


Testing
---


Thanks,

Dineshkumar Yadav

Review Request 74129: RANGER-3920 When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing

[Ankita Sinha]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74129/
---

Review request for ranger, Madhan Neethiraj, Mehul Parikh, Monika Kachhadiya, 
Pradeep Agrawal, Siddhesh Phatak, Sailaja Polavarapu, and Subhrat Chaudhary.


Bugs: RANGER-3920
https://issues.apache.org/jira/browse/RANGER-3920


Repository: ranger


Description
---

Problem Statement:
=
Currently, Usersync sync's users/groups/usergroup in batches. In doing so, the 
user/group/usergroup at the end of the batch is not sync'ed. 
For example consider batch is of size 1000, so batch starts from 0-999 and  
then  next batch starts from 1001-1999. So in each batch one 
user/group/usergroup is missing.

Solution:

Updated code to handle this missing one user in each batch.


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
 654b83282 


Diff: https://reviews.apache.org/r/74129/diff/1/


Testing
---

Tested with large number user/group/usergroup membership if all the 
user/group/usergroup membership is getting sync'ed in Ranger admin


Thanks,

Ankita Sinha

[jira] [Updated] (RANGER-3920) When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing

[Ankita Sinha (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ankita Sinha updated RANGER-3920:
-
Description: 
Problem Statement:

Currently, Usersync sync's users/groups/usergroup in batches. In doing so, the 
user/group/usergroup at the end of the batch is not sync'ed. 
For example consider batch is of size 1000, so batch starts from 0-999 and  
then  next batch starts from 1001-1999. So in each batch one 
user/group/usergroup is missing.

 

  was:
Problem Statement:

Usersync sync's user/group/usergroup membership in batches. For example 
consider batch is of size 1000. So batch start from 0-999 and next batch starts 
from 1001-1999. So in each batch one user count missing.

 


> When sync'ing users from Ldap,  intermittent User/Group/UserGroup membership  
> is missing
> 
>
> Key: RANGER-3920
> URL: https://issues.apache.org/jira/browse/RANGER-3920
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger, usersync
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
>Priority: Major
> Fix For: 2.4.0
>
>
> Problem Statement:
> Currently, Usersync sync's users/groups/usergroup in batches. In doing so, 
> the user/group/usergroup at the end of the batch is not sync'ed. 
> For example consider batch is of size 1000, so batch starts from 0-999 and  
> then  next batch starts from 1001-1999. So in each batch one 
> user/group/usergroup is missing.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-3920) When sync'ing users from Ldap, intermittent User/Group/UserGroup membership is missing

[Ankita Sinha (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ankita Sinha updated RANGER-3920:
-
Summary: When sync'ing users from Ldap,  intermittent User/Group/UserGroup 
membership  is missing  (was: In Ldap usersync one User/Group/UserGroup 
membership is missed in each batch when pushed to ranger)

> When sync'ing users from Ldap,  intermittent User/Group/UserGroup membership  
> is missing
> 
>
> Key: RANGER-3920
> URL: https://issues.apache.org/jira/browse/RANGER-3920
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger, usersync
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
>Priority: Major
> Fix For: 2.4.0
>
>
> Problem Statement:
> Usersync sync's user/group/usergroup membership in batches. For example 
> consider batch is of size 1000. So batch start from 0-999 and next batch 
> starts from 1001-1999. So in each batch one user count missing.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-3920) In Ldap usersync one User/Group/UserGroup membership is missed in each batch when pushed to ranger

[Ankita Sinha (Jira)]

 [ 
https://issues.apache.org/jira/browse/RANGER-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ankita Sinha updated RANGER-3920:
-
Description: 
Problem Statement:

Usersync sync's user/group/usergroup membership in batches. For example 
consider batch is of size 1000. So batch start from 0-999 and next batch starts 
from 1001-1999. So in each batch one user count missing.

 

  was:In Ldap usersync one User/Group/UserGroup membership is missed in each 
batch when pushed to ranger


> In Ldap usersync one User/Group/UserGroup membership is missed in each batch 
> when pushed to ranger
> --
>
> Key: RANGER-3920
> URL: https://issues.apache.org/jira/browse/RANGER-3920
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger, usersync
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
>Priority: Major
> Fix For: 2.4.0
>
>
> Problem Statement:
> Usersync sync's user/group/usergroup membership in batches. For example 
> consider batch is of size 1000. So batch start from 0-999 and next batch 
> starts from 1001-1999. So in each batch one user count missing.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3920) In Ldap usersync one User/Group/UserGroup membership is missed in each batch when pushed to ranger

[Ankita Sinha (Jira)]

Ankita Sinha created RANGER-3920:


 Summary: In Ldap usersync one User/Group/UserGroup membership is 
missed in each batch when pushed to ranger
 Key: RANGER-3920
 URL: https://issues.apache.org/jira/browse/RANGER-3920
 Project: Ranger
  Issue Type: Bug
  Components: admin, Ranger, usersync
Reporter: Ankita Sinha
Assignee: Ankita Sinha
 Fix For: 2.4.0


In Ldap usersync one User/Group/UserGroup membership is missed in each batch 
when pushed to ranger



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74122: RANGER-3914: Change sync_source column's datatype from varchar to text

[Kirby Zhou]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/74122/#review224683
---



A lot of varchar(4000) remained, why we keep them unchanged?


security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql
Line 371 (original), 371 (patched)


Why do not change this to text?
There are a lot of VARCHAR(4000) / VARCHAR2(4000) left unchanged.


- Kirby Zhou


On 九月 16, 2022, 6:12 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74122/
> ---
> 
> (Updated 九月 16, 2022, 6:12 a.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Nikhil P, 
> Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja Polavarapu, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3914
> https://issues.apache.org/jira/browse/RANGER-3914
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:**
> Ranger install or upgrade may fail with below error when mysql engine having 
> database charset set to utfmb4.
> 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
> Row size too large. The maximum row size for the used table type, not 
> counting BLOBs, is 65535. 
> This includes storage overhead, check the manual. You have to change some 
> columns to TEXT or BLOBs
> 
> SQLException : SQL state: 42000 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Row size too 
> large. The maximum row size for the used table type, not counting BLOBs, is 
> 65535. This includes storage overhead, check the manual. You have to change 
> some columns to TEXT or BLOBs ErrorCode: 1118
> 
> **Proposed solution:**
> Since BLOBs are not counted in the calculation of row size we can change 
> sync_source column type to Blob/text/clob type.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 309c4196b 
>   
> security-admin/db/mysql/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  a23976b80 
>   
> security-admin/db/mysql/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  5a40a89e0 
>   
> security-admin/db/mysql/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> 1af0a04ac 
>   
> security-admin/db/oracle/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  3fc4b975d 
>   
> security-admin/db/oracle/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  ed8dbaf7f 
>   
> security-admin/db/oracle/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> baa6288d2 
>   
> security-admin/db/postgres/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  b1e8c3845 
>   
> security-admin/db/postgres/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  68117a123 
>   
> security-admin/db/postgres/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  5e8070ba2 
>   
> security-admin/db/sqlanywhere/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  38a85e97b 
>   
> security-admin/db/sqlanywhere/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  335459058 
>   
> security-admin/db/sqlanywhere/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> 8b5833eae 
>   
> security-admin/db/sqlserver/patches/045-add-displayName-col-in-x_service_def_and_x_service.sql
>  ae216445b 
>   
> security-admin/db/sqlserver/patches/055-add-syncSource-col-in-x_user-x_portal_user-x_group.sql
>  3b8a8d83a 
>   
> security-admin/db/sqlserver/patches/060-change-syncsrc-col-datatype-x_user-x_portal_user-x_group.sql
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/74122/diff/3/
> 
> 
> Testing
> ---
> 
> Tested Ranger install and upgrade with this patch which was failing earlier.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>

[jira] [Commented] (RANGER-3919) Adding automatically terminate a session after a predefined timeout period (60 minutes) of inactivity.

[kirby zhou (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606956#comment-17606956
 ] 

kirby zhou commented on RANGER-3919:


Session timeout (default 60m)is controlled by web.xml which is not in conf 
directory. So our default conf  ranger.admin.kerberos.token.valid.seconds = 30s 
(second) is meaningless.

 

Mentioned in  https://issues.apache.org/jira/browse/RANGER-3635

 

And there is a mechanism to keep the session renewed, even if kerberos ticket 
has expired.

 

 

> Adding automatically terminate a session  after a predefined timeout period 
> (60 minutes) of inactivity. 
> 
>
> Key: RANGER-3919
> URL: https://issues.apache.org/jira/browse/RANGER-3919
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Sanjay Kumar Sahu
>Priority: Major
>
> Web applications do not automatically terminate a session 
> after a predefined timeout period (60 minutes) of inactivity. 
> Adding automatically terminate a session 
> after a predefined timeout period (60 minutes) of inactivity. 
> This issue increases the window of opportunity for an attacker to gain 
> unauthorized access to a user’s session. However, in order to exploit this 
> issue, an attacker still needs to obtain a 
> valid session ID tokens.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RANGER-3775) Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606952#comment-17606952
 ] 

Ramachandran edited comment on RANGER-3775 at 9/20/22 7:13 AM:
---

[~kirbyzhou]   Got it. sql_appender should be used by log4jdbc only. As well as 
logger name  com.mchange  needs to be included as part of appender called 
xa_log_appender

 


was (Author: JIRAUSER295265):
[~kirbyzhou]   Got it. sql_appender should be used by log4jdbc only. As well as 
logger name  com.mchange  will be included as part of  appender called 
xa_log_appender

 

> Logback.xml has been incorrectly modified by RANGER-3704.
> -
>
> Key: RANGER-3775
> URL: https://issues.apache.org/jira/browse/RANGER-3775
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: kirby zhou
>Priority: Critical
>
> {code:java}
> git show 361f179249 | filterdiff -i '*/logback.xml'
> diff --git a/security-admin/src/main/webapp/WEB-INF/logback.xml 
> b/security-admin/src/main/webapp/WEB-INF/logback.xml
> index 997f3bc59..53cdc49cf 100644
> --- a/security-admin/src/main/webapp/WEB-INF/logback.xml
> +++ b/security-admin/src/main/webapp/WEB-INF/logback.xml
> @@ -80,7 +80,7 @@
>    
>      
>    
> -  
> +  
>      
>    
>     
> {code}
> These changes seems not related to the issue RANGER-3704.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RANGER-3775) Logback.xml has been incorrectly modified by RANGER-3704.

[Ramachandran (Jira)]

[ 
https://issues.apache.org/jira/browse/RANGER-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606952#comment-17606952
 ] 

Ramachandran commented on RANGER-3775:
--

[~kirbyzhou]   Got it. sql_appender should be used by log4jdbc only. As well as 
logger name  com.mchange  will be included as part of  appender called 
xa_log_appender

 

> Logback.xml has been incorrectly modified by RANGER-3704.
> -
>
> Key: RANGER-3775
> URL: https://issues.apache.org/jira/browse/RANGER-3775
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: kirby zhou
>Priority: Critical
>
> {code:java}
> git show 361f179249 | filterdiff -i '*/logback.xml'
> diff --git a/security-admin/src/main/webapp/WEB-INF/logback.xml 
> b/security-admin/src/main/webapp/WEB-INF/logback.xml
> index 997f3bc59..53cdc49cf 100644
> --- a/security-admin/src/main/webapp/WEB-INF/logback.xml
> +++ b/security-admin/src/main/webapp/WEB-INF/logback.xml
> @@ -80,7 +80,7 @@
>    
>      
>    
> -  
> +  
>      
>    
>     
> {code}
> These changes seems not related to the issue RANGER-3704.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)