; -Original Message-
> From: John Sichi [mailto:jsi...@facebook.com]
> Sent: Wednesday, October 13, 2010 4:36 PM
> To:
> Cc: howl...@yahoogroups.com; Pradeep Kamath;
> Subject: Re: [howldev] RE: Howl Authorization proposal
>
> On Oct 13, 2010, at 9:22 AM, Alan Gates wr
...@yahoogroups.com;
Subject: RE: [howldev] RE: Howl Authorization proposal
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
: RE: [howldev] RE: Howl Authorization proposal
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
lowed in one is the
same in the other might be difficult - thoughts?
-Original Message-
From: John Sichi [mailto:jsi...@facebook.com]
Sent: Wednesday, October 13, 2010 4:36 PM
To:
Cc: howl...@yahoogroups.com; Pradeep Kamath;
Subject: Re: [howldev] RE: Howl Authorization proposal
On O
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
John,
It's not clear to us whether, if a traditional ACL model was
available, we would still need the HDFS model. I suspect so, but I'm
not sure.
We had a few concerns with the full ACL model that caused us to avoid
it at least initially. In this model Hive/Howl has to own all the
fil
Hi Pradeep,
Namit and I took a look at the doc; thanks for the clear writeup.
Coincidentally, we've been starting to think about some Hive authorization use
cases within Facebook as well. However, the approach we're thinking about is
more along the lines of traditional SQL ACL's (role-based GR
