One more addition to what Thejas mentioned - BitSetCheckAuthorizationProvider was the old legacy method of authorization in hive that was replaced in use-intent by SQLStandardAuthorization. I think we should look to deprecating and removing that now.
In general, if you want conventional db-like grant/revoke style authorzation, you should go with SQLStandardAuth, and if you want file-system-permission-based, you should look at StorageBasedAuthorizationProvider. On Fri, Aug 19, 2016 at 10:58 AM, Thejas Nair <thejas.n...@gmail.com> wrote: > 1 - if it set to true, you need to manager permissions in two places for > users, using grant/revoke on tables, and file system permissions as well, > and keep them in sync. That will be a headache. > Moreover, the main intent for sql std auth is to be able to provide fine > grained access control using views (access to only certain columns/rows). To > allow users to change file system permissions, you need to allow them access > to file system, which means you can't do fine grained access control. > > 2. The principal specified in the connect string is to indicate what > service principal is, it is not the principal of the user who is connecting. > You can kinit as any user. > doas setting does not affect authentication. > > 3. The grant/revoke not having any privilege requirements was an issue in > the old default legacy auth. It is not an issue in SQL std auth. > hive.users.in.admin.role is used to set the list of admin users. > > > 4. You can use SQL auth with storage based if you have certain users who > access metastore without going through HS2, for example hive cli users. > > > > On Thu, Aug 18, 2016 at 12:41 AM, Maria <linanmengxia...@126.com> wrote: >> >> >> Hi,all: >> I have a few questions about hive authentication and authorization: >> >> (1)why do we need to set hive.server2.enable.doAs=false in SQL-Standard >> Based Authorization ? >> >> (2)when set hive.server2.enable.doAs=false in SQL-Standard Based >> Authorization,the beeline way to connecte HS2, >> the queries are run as the service user id of HiverServer2, how to make it >> use the users who is in current kerberos ticket cache? >> （because if "hive.server2.enable.doAs=false" and hive uri is like >> this——"jdbc:hive2://cdh1:10000/default;principal=hive/c...@javachen.com"， >> the kerberos ticket cache will not work.） >> >> (3)Does hive 1.2.1 and later version still has grant/revoke BUG?——I found >> someone said >> that user needs to imply administrator privilege according to implements >> AbstractSemanticAnalyzerHook,if >> he want to let the administrator own the grant/revoke privilege only. But >> I also found a parameter >> "hive.users.in.admin.role",does this param makes up this deficiency？ >> >> (4)Must I start up hive metastore service when SQL Standards Based Hive >> Authorization in conjunction >> with storage based authorization？（ >> https://cwiki.apache.org/confluence/display/Hive/SQL+Standard+Based+Hive+Authorization），and >> if the two combined, “hive.server2.enable.doAs" set to false? >> >> (5)Can someone please give me a tip on this class: >> BitSetCheckAuthorizationProvider? if I can >> set >> "hive.security.authorization.manager=org.apache.hadoop.hive.ql.security.authorization.BitSetCheckAuthorizationProvider"?What >> are the difference between BitSetCheckAuthorizationProvider and >> SQLStdHiveAuthorizerFactory? >> >> >> I am confused by these questions for a long time. I am eager to get your >> guidance. >> >> Any reply will be much appreciated. >> And thankyou again. >> >> >> >
