Hi Lenni, Please see my description in SENTRY-944:
Two calls are executed in the deep stack: a. dir.setOwner(src, username, group); b. getEditLog().logSetOwner(src, username, group); The first call is the one gets rejected by Sentry, however, the second one still updates the entry to Edit log. This would indicate an inconsistency between HDFS in-memory representation of the attribute and what's recorded on edit log. Always falling through would remove the inconsistency. Thanks. --Yongjun On Tue, Dec 15, 2015 at 4:18 PM, Lenni Kuff <[email protected]> wrote: > Interesting. Could you expand on how this would lead to inconsistencies in > the edit log? > > Thanks, > Lenni > > On Tue, Dec 15, 2015 at 3:54 PM, Sravya Tirukkovalur <[email protected]> > wrote: > > > Hi all, > > > > Looks like due to the reasons specified here in the jira: > > https://issues.apache.org/jira/browse/SENTRY-988 , it is better to fall > > through to change the defaultProviders's rules in all the setter > functions > > in the HDFS Sentry plugin. This was the behavior before SENTRY-944. We > > changed the behavior in SENTRY-944 as a way to clean up the asymmetry but > > turns out this might lead to inconsistency in edit log. So I think we > > should change back the behavior. Let me know what you think? > > > > Regards, > > -- > > Sravya Tirukkovalur > > >
