Grokbase Groups Hive dev October 2010

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.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 8 | next ›
Discussion Overview
groupdev @
categorieshive, hadoop
postedOct 5, '10 at 8:43p
activeOct 14, '10 at 3:12a



site design / logo © 2021 Grokbase