[
https://issues.apache.org/jira/browse/RANGER-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Nadar updated RANGER-4697:
--------------------------------
Description:
Steps to reproduce:
1. Create a datashare DSH-1, with zone1 and service1
2. Now download the GDS cache for service1. Note down the gds version as well
(The response has the security zone name)
3. Now modify the zoneName to zone-test.
4. Now check the response of GDS cache download api, it's gds version would not
be incremented and it will also contain the old security zone name.
5. Due to this the access enforcement fails.
When the zone name is modified, then the gds version is not updated. (Because
the datshare object contains the zoneID and therefore the zone name change does
not affect the object)
However, the GDS cache contains the security zone name which is used to
evaluate access.
But this new change of zone name is not taken by the cache because the service
specific gds version is not updated. And because of this the access enforcement
fails for GDS policies.
Resolution:
To address this issue, upon modification of the zone name, the service-specific
GDS versions for all services associated with that particular zone must be
updated, if they are associated with a datashare.
was:
Steps to reproduce:
1. Create a datashare DSH-1, with zone1 and service1
2. Now download the GDS cache for service1. Note down the gds version as well
(The response has the security zone name)
3. Now modify the zoneName to zone-test.
4. Now check the response of GDS cache download api, it's gds version would not
be incremented and it will also contain the old security zone name.
5. Due to this the access enforcement fails.
When the zone name is modified, then the gds version is not updated. (Because
the datshare object contains the zoneID and therefore the zone name change does
not affect the object)
However, the GDS cache contains the security zone name which is used to
evaluate access.
But this new change of zone name is not taken by the cache because the service
specific gds version is not updated. And because of this the access enforcement
fails for GDS policies.
To address this issue, upon modification of the zone name, the service-specific
GDS versions for all services associated with that particular zone must be
updated, if they are associated with a datashare.
> GDS: The GDS cache is not updated when the name of a security zone is
> modified which is linked with a datashare
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-4697
> URL: https://issues.apache.org/jira/browse/RANGER-4697
> Project: Ranger
> Issue Type: Bug
> Components: admin
> Reporter: Anand Nadar
> Assignee: Anand Nadar
> Priority: Major
>
> Steps to reproduce:
> 1. Create a datashare DSH-1, with zone1 and service1
> 2. Now download the GDS cache for service1. Note down the gds version as well
> (The response has the security zone name)
> 3. Now modify the zoneName to zone-test.
> 4. Now check the response of GDS cache download api, it's gds version would
> not be incremented and it will also contain the old security zone name.
> 5. Due to this the access enforcement fails.
> When the zone name is modified, then the gds version is not updated. (Because
> the datshare object contains the zoneID and therefore the zone name change
> does not affect the object)
> However, the GDS cache contains the security zone name which is used to
> evaluate access.
> But this new change of zone name is not taken by the cache because the
> service specific gds version is not updated. And because of this the access
> enforcement fails for GDS policies.
> Resolution:
> To address this issue, upon modification of the zone name, the
> service-specific GDS versions for all services associated with that
> particular zone must be updated, if they are associated with a datashare.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
