Madhan, Thanks, I think I understand the difference now.
Just so I understand, how do you create a deny policy? Thanks, Bryan On Fri, Apr 8, 2016 at 10:15 AM, Madhan Neethiraj <[email protected]> wrote: > Bryan, > > In this scenario, Ranger did not have a policy to either allow or deny > the requested access. > > Returning "isAccessDetermined=false, isAllowed=false” is necessary here > so that the callers can differentiate between Ranger actively denying a > request (via a deny policy) vs no policy to determine the access. > > Such a distinction is used by some plugins (like HDFS, YARN) to decide > whether to fallback to their native authorization or simply deny the > access. Other plugins (like Hive, Knox, Storm, Kafka) simply deny the > access when isAllowed=false - since there was no need/option to fallback > to their native authorization. > > Hope this helps. > > Madhan > > > > On 4/8/16, 6:48 AM, "Bryan Bende" <[email protected]> wrote: > > >Thanks Madhan, that is helpful. > > > >The scenario that is confusing me is this... I defined a policy for a > >resource, lets say "resource1", and I add "admin" user with "read" > >permission. > > > >Then I make an access request for "resource1" as the "admin" user for an > >action type of "write" (different action from policy above). > > > >This returns isAccessDetermined false and isAllowed false, which as you > >described means "Access not-determined". > > > >Why is isAccessDetermined false in this case? I thought this would have > >been isAccessDetermined true and isAllowed false because of the action not > >matching the permission. > > > >Thanks, > > > >Bryan > > > > > > > >On Thu, Apr 7, 2016 at 5:48 PM, Madhan Neethiraj <[email protected]> > wrote: > > > >> Bryan, > >> > >> Ranger policy model has been updated to be able to actively deny access. > >> This enhancement is already in the master and will be included in the > next > >> release - ranger-0.6. > >> > >> When an access is denied by Ranger, RangerAccessResult will have: > >> isAccessDetermined=true; isAllowed=false. > >> > >> > >> Here are the possible combinations: > >> -------------------------------------------------------------- > >> | # | isAccessDetermined | isAllowed | Comment | > >> |------------------------|-----------|------------------------| > >> | 1 | True | True | Access Allowed | > >> |------------------------------------|------------------------| > >> | 2 | False | False | Access not-determined | > >> > >> |------------------------------------|------------------------| > >> | 3 | True | False | Access Denied | > >> |------------------------------------|------------------------| > >> | 4 | False | True | Invalid result | > >> -------------------------------------------------------------- > >> > >> > >> > >> > >> In case of #2, the components can choose to: > >> - deny the access: this is done by Hive, Storm, Knox > >> - fallback to native access-control: this is done by HDFS, YARN > >> > >> > >> #4 is an invalid combination and this will not be returned by Ranger. > >> > >> Hope this helps. > >> > >> Madhan > >> > >> On 4/7/16, 1:21 PM, "Bryan Bende" <[email protected]> wrote: > >> > >> >Hello, > >> > > >> >What does isAccessDetermined mean on RangerAccessResult? > >> > > >> >From testing it seems like isAccessDetermined and isAllowed will both > be > >> >true when the user has access to the resource, and then they will both > be > >> >false in other cases. > >> > > >> >Is there ever a case where isAllowed is false, and isAccessDetermined > is > >> >true? > >> > > >> >Thanks, > >> > > >> >Bryan > >> > >> > >
