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
