sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <>
Subject [jira] [Created] (SENTRY-27) Refactor to be able to support different provider backends (e.g. db vs file)
Date Tue, 01 Oct 2013 00:01:24 GMT
Gregory Chanan created SENTRY-27:

             Summary: Refactor to be able to support different provider backends (e.g. db
vs file)
                 Key: SENTRY-27
             Project: Sentry
          Issue Type: Sub-task
    Affects Versions: 1.2.0
            Reporter: Gregory Chanan
            Assignee: Gregory Chanan
             Fix For: 1.2.0, 1.3.0

see this review request:

Here's the part that is relevant to this JIRA (note: this is just refactoring to be able to
support other backends, this is not support for other backends).

The issue right now is the sentry-provider-file and sentry-provider-hive have things that
are both backend-specific (e.g. PolicyFileConstants) and backend-agnostic (e.g. HadoopMappingService).
 Let's take an specific use case: we want to use the HadoopGroupResourceAuthorizationProvider
via a database-backend.  If today I specify the AuthorizationProvider to be say "org.apache.sentry.provider.hive.HadoopGroupResourceAuthorizationProvider"
it will automatically be file-backed because it automatically instantiates a SimpleHivePolicyEngine
which in turn uses the file.SimplePolicyParser.  So, we should separate out the specification
of the AuthorizationProvider and the PolicyEngine.  So I would specify the AuthorizationProvider
to be "org.apache.sentry.provider.hive.HadoopGroupResourceAuthorizationProvider" and the PolicyEngine
to be "org.apache.sentry.policyengine.db.DBPolicyEngine" (that example sort of sucks because
it has db twice -- maybe dbbackend.DBPolicyEngine).  I think that is pretty similar to what
you are saying -- just using "PolicyEngine" or "Policy" instead of "Permission Implementation".

In my mind, there are 6 different files-types here, if we assume support for file/db backends
and db/solr services:
Policy-Engine Specific {common, db, solr}
Non-Policy-Engine Specific {common, file, db}

Now I don't have a huge preference for where this should all go, except that the policy-engine
specific stuff for db and solr should be in their own package, to avoid pulling in a bunch
of dependencies if they aren't needed.  So this could be something like:

Or we could just throw all the "common" stuff into core.

This message was sent by Atlassian JIRA

View raw message