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

Hrishikesh Gadre commented on SENTRY-2178:
------------------------------------------

It looks like the following defensive check in the code failed to handle this 
case,

[https://github.com/apache/sentry/blob/f557a0380cf0ddc250010d4eb1b49e127f86f271/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/generic/tools/PermissionsMigrationToolCommon.java#L269-L272]

The root cause is that the equals method in TSentryPrivilege object performs 
case sensitive comparison of component string. When we convert TSentryPrivilege 
object from string representation, the component name is set as SOLR. On the 
other hand TSentryPrivilege object prepared from database state has the 
component name as solr. Due to this the original permission can not be found in 
the converted permissions resulting in incorrect revocation.

The fix would be to ensure that we use case insensitive comparison of 
permission strings (instead of TSentryPrivilege objects).

 

 

> Sentry permissions for Solr are deleted as part of migration process
> --------------------------------------------------------------------
>
>                 Key: SENTRY-2178
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2178
>             Project: Sentry
>          Issue Type: Bug
>          Components: Solr Plugin
>    Affects Versions: 2.0.0
>            Reporter: Hrishikesh Gadre
>            Assignee: Hrishikesh Gadre
>            Priority: Critical
>
> SENTRY-1480 implemented a command-line tool to migrate Sentry permissions 
> from 1.x to 2.x. During upgrade testing I found a bug in the migration 
> process where the pre-upgrade permissions are deleted. Specifically following 
> permission was configured on Sentry v1
> {noformat}
> collection=*->action=*
> {noformat}
> After the migration, following permissions were available on Sentry service
> {noformat}
> admin=collections->action=*
> admin=cores->action=*
> {noformat}
> Note that the original permission is missing. From the following log snippet 
> of Sentry service, it looks like the original permission was incorrectly 
> revoked.
> {noformat}
> 2018-03-08 21:40:20,856 INFO DataNucleus.Datastore: Collection field 
> "org.apache.sentry.provider.db.service.model.MSentryRole.gmPrivileges" of 
> "org.apache.sentry.provider.db.service.model.MSentryRole@4dc76fa5" was asked 
> to add element "MSentryGMPrivilege [serverName=service1, componentName=solr, 
> authorizables=Admin=collections, scope=Admin, action=*, roles=[...], 
> createTime=1520574020823, grantOption=false]" to the M-N bidirectional 
> relation but the element already has this field in its collection (maybe 
> added from the other side)
> 2018-03-08 21:40:20,997 INFO sentry.generic.authorization.ddl.logger: 
> \{"serviceName":"Sentry-Service","userName":"solr","impersonator":"s...@gce.cloudera.com","ipAddress":"/172.31.117.188","operation":"GRANT_PRIVILEGE","eventTime":"1520574020991","operationText":"GRANT
>  ALL ON Admin collections TO ROLE solr-admin ON COMPONENT 
> SOLR","allowed":"true","databaseName":null,"tableName":null,"column":null,"resourcePath":null,"objectType":"PRINCIPAL"}
> 2018-03-08 21:40:21,015 INFO DataNucleus.Datastore: Collection field 
> "org.apache.sentry.provider.db.service.model.MSentryRole.gmPrivileges" of 
> "org.apache.sentry.provider.db.service.model.MSentryRole@46f3fe41" was asked 
> to add element "MSentryGMPrivilege [serverName=service1, componentName=solr, 
> authorizables=Admin=cores, scope=Admin, action=*, roles=[...], 
> createTime=1520574021011, grantOption=false]" to the M-N bidirectional 
> relation but the element already has this field in its collection (maybe 
> added from the other side)
> 2018-03-08 21:40:21,022 INFO sentry.generic.authorization.ddl.logger: 
> \{"serviceName":"Sentry-Service","userName":"solr","impersonator":"s...@gce.cloudera.com","ipAddress":"/172.31.117.188","operation":"GRANT_PRIVILEGE","eventTime":"1520574021022","operationText":"GRANT
>  ALL ON Admin cores TO ROLE solr-admin ON COMPONENT 
> SOLR","allowed":"true","databaseName":null,"tableName":null,"column":null,"resourcePath":null,"objectType":"PRINCIPAL"}
> 2018-03-08 21:40:21,035 INFO sentry.generic.authorization.ddl.logger: 
> \{"serviceName":"Sentry-Service","userName":"solr","impersonator":"s...@gce.cloudera.com","ipAddress":"/172.31.117.188","operation":"GRANT_PRIVILEGE","eventTime":"1520574021035","operationText":"GRANT
>  ALL ON Collection * TO ROLE solr-admin ON COMPONENT 
> SOLR","allowed":"true","databaseName":null,"tableName":null,"column":null,"resourcePath":null,"objectType":"PRINCIPAL"}
> 2018-03-08 21:40:21,080 INFO sentry.generic.authorization.ddl.logger: 
> \{"serviceName":"Sentry-Service","userName":"solr","impersonator":"s...@gce.cloudera.com","ipAddress":"/172.31.117.188","operation":"REVOKE_PRIVILEGE","eventTime":"1520574021080","operationText":"REVOKE
>  ALL ON Collection * FROM ROLE solr-admin ON COMPONENT 
> SOLR","allowed":"true","databaseName":null,"tableName":null,"column":null,"resourcePath":null,"objectType":"PRINCIPAL"}
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to