Thanks for the explanation, that makes sense. I'm +1 for allowing set*/remove* operations to happen on the underlying HDFS ACLs (defaultProvider). Seems like the right thing to do so the edit logs are consistent. It would be nice if we could log in the plugin (HDFS logs) that the operation will not be visible in the shadowed ACLs. I'm thinking about the case were someone does setAcl on a Sentry managed path, then does a getAcl and doesn't see the change applied.
Thanks, Lenni On Tue, Dec 15, 2015 at 10:24 PM, Yongjun Zhang <[email protected]> wrote: > 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 > > > > > >
