ALTER TABLE statement contains a lot of operations. it can be altering table's metadata or altering table's data, or create new partitions etc. So ALTER TABLE should not all have the identical privilege control. Each alter table operation has its own name internally in hive, so they can have more fine grained permission control.
On Wed, Mar 23, 2011 at 9:45 AM, Jonathan Natkins <na...@cloudera.com> wrote: > Thanks a lot for the response, Yongqiang! Just a thought, inline. > > On Tue, Mar 22, 2011 at 7:28 PM, yongqiang he <heyongqiang...@gmail.com> > wrote: >> >> >>INDEX - my best guess is that this allows me to create/drop indexes on a >> table? >> Yes. It is there for this purpose. >> >> >> Is it the case that if I have select access on a table, I can use >> any index that exists on a table? >> No. index is also a table now, so you need to have access to both of them. >> >> >>LOCK - Presumably this allows users to lock or unlock a table, so maybe >> >> a >> better question is: are these locks like mutexes, where only I can access >> the table, or is this literally locking down the table, so it can't be >> modified in any way? >> >> Yes. If only you have lock privilege on this table, and concurrency is >> enabled, no one will be able to run anything against the table. >> >> >>SHOW_DATABASE - I'm not sure what the scope of this one is: if I don't >> >> have >> show_database access, can I not use the show database command? >> >> if you don't have show_database access, you should not be able to use >> the show database command. I do not think today this privilege is >> supported. >> >> >> create access on a table doesn't seem to have a lot of semantic value >> i think create on a table means create partition > > This seems really unintuitive to me, given that partitions are created > through an ALTER TABLE statement. Wouldn't they fall under the umbrella of > operations that require ALTER permission? >> >> >>Similarly, I'm having a hard time rationalizing why I can grant >> >> SHOW_DATABASE on a table. >> This should be a bug. Basically each privilege has its set of scope, >> (can apply to db level or table level or column or user level, >> non-exclusive) >> >> Thanks >> Yongqiang >> On Tue, Mar 22, 2011 at 6:30 PM, Jonathan Natkins <na...@cloudera.com> >> wrote: >> > Hi all, >> > >> > I'm trying to understand the meaning of some of the privileges in the >> > system, and I'm a bit stumped on what some of them actually do. >> > >> > Privileges that confuse me: >> > INDEX - my best guess is that this allows me to create/drop indexes on a >> > table? Is it the case that if I have select access on a table, I can >> > use >> > any index that exists on a table? >> > LOCK - Presumably this allows users to lock or unlock a table, so maybe >> > a >> > better question is: are these locks like mutexes, where only I can >> > access >> > the table, or is this literally locking down the table, so it can't be >> > modified in any way? >> > SHOW_DATABASE - I'm not sure what the scope of this one is: if I don't >> > have >> > show_database access, can I not use the show database command? Or does >> > this >> > extend to not being able to see the tables within a database? >> > >> > It seems like you can grant some privileges on objects that don't have a >> > lot >> > of meaning, i.e. create access on a table doesn't seem to have a lot of >> > semantic value, unless Hive requires that permission to create indexes >> > on a >> > table, or something along those lines. Similarly, I'm having a hard >> > time >> > rationalizing why I can grant SHOW_DATABASE on a table. >> > >> > Thanks a lot, >> > Jon >> > > >
