Sasha, I agree.
There several issues in current sentry solution. 1) Changing permission on one table could cause update on wild card permission on database. We can use policy-based approach to specify permission. So updating one policy does not require update of other policies. When determine the permissions, all match policies are applied in order of priority. The highest policy has the final say. 2) Sentry update the query. It makes it hard to support different types of DB. As you mentioned, Sentry service should return the permission info to caller, and caller should update query to enforce the permission. The caller can be Sentry client plugin, but not part of Sentry service. Thanks, Lina Sent from my iPhone > On Jun 10, 2017, at 2:26 AM, Alexander Kolbasov <[email protected]> wrote: > > I was wondering why our Sentry Server, which is, essentially, a wrapper > around the storage layer is so complex. It seems that a lot of complexity > (putting HDFS sync aside) is coming from the fact that the Sentry Server > knows too much about HMS semantics. For example, the only reason we need to > have synchronization between HMS and Sentry in Sentry HA is because Sentry > actually modifies permissions on tables and databases when some permissions > actions are performed. Also it is very smart about understanding composite > ALL permissions. > > I think we can simplify this model a LOT if we separate the knowledge. > Sentry Server should be just a storage of information - it shouldn't have any > smartness in it. It should store roles an groups and permissions and allow > callers to store and modify these objects but it shouldn't understand what > they actually mean. It is up to the consumers (HMS, for example) to make > smart decisions about what is ALL permissions, or what should change when a > table is dropped. Sentry server shouldn't be in the business of changing > permissions on drop table event - HMS should do that instead. > > This will also simplify us to use one truly generic model for HMS and all > other components - the model would be just the data representation for roles > groups and permissions. > > I think this will untangle a lot of the current complexity mess. > > Any thoughts on this? > > - Alex > -- > You received this message because you are subscribed to the Google Groups > "sentry-ha" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/cloudera.com/d/msgid/sentry-ha/CAGGNey3TaY_KXj--aC3%3D7LU2ixUoeJijyUuvf9tn7h37mVs9Gg%40mail.gmail.com.
