I shared the same opinion about Sentry server with you Sasha. Although, probably the contributors with more time experience on Sentry would know the reason for the design approach of the Sentry server.
On Sat, Jun 10, 2017 at 8:35 PM, Na Li <[email protected]> wrote: > 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. >
