hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pradeep Kamath <prade...@yahoo-inc.com>
Subject RE: [howldev] RE: Howl Authorization proposal
Date Wed, 13 Oct 2010 23:49:57 GMT
One related concern with not using hdfs permissions is that there can be conflicts between
what the hive authorization realm would permit versus what hdfs would permit.

For instance a user X (in the hive authorization realm) has create table privilege for database
db1 but the hdfs directory /user/hive/warehouse/db1 is actually not writable by user X - wouldn't
this lead to a dfs permissions denied error though user X has the create privilege per hive?
We can extend the same issue to other operations like drop table etc. 

Keep the two worlds in sync so that what is allowed/disallowed in one is the same in the other
might be difficult - thoughts?

-----Original Message-----
From: John Sichi [mailto:jsichi@facebook.com] 
Sent: Wednesday, October 13, 2010 4:36 PM
To: <dev@hive.apache.org>
Cc: howldev@yahoogroups.com; Pradeep Kamath; <hive-dev@hadoop.apache.org>
Subject: Re: [howldev] RE: Howl Authorization proposal

On Oct 13, 2010, at 9:22 AM, Alan Gates wrote:

> Our biggest concern is that HDFS already has a permissions model, why create a whole
new one?  It is a lot of duplication.  And that duplication will flow through to things like
logging and auditing, all of which Hive/Howl will now need in addition to HDFS.  To justify
this we needed to understand what additional benefits a traditional ACL model would get us.
 We were not able to come up with compelling use cases where we had to have this traditional
model.

Here are some you probably already considered, but I'm listing them for consideration anyway...

* table A can only be queried by roles X and Y; table B can only be queried by roles Y and
Z; managing different groups for all the possible role combinations isn't very practical given
large numbers of tables and roles
 
* finer-grained access control (e.g. column-level) may not be expressible in terms of HDFS
permissions without doing things like creating dummy files (although in SQL, views can be
used to avoid column-level permissions)

* privileges beyond read/write (e.g. delete vs update vs append)

* (Hive-specific):  GRANT/REVOKE is the standard SQL approach and requires ACL's (it can't
be implemented in terms of HDFS permissions)

> All that said, I see no problem with having two models for now, and seeing which turns
out to better provide what users need and/or be easier to maintain.


OK, let us know if the hooks turn out to be insufficient as the implementation mechanism.

JVS


Mime
View raw message