Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - Discussion on Namespace permissions


Copy link to this message
-
Re: Discussion on Namespace permissions
Mike Drob 2013-12-06, 16:08
It is absolutely useful to grant users full access within a namespace and
no access outside of it. If I'm running some experiments then let me (and
possibly the rest of my team) create and drop to heart's content in our own
personal area and don't worry about the rest of the system.

Having a permission to create namespaces is also good because you can then
separate various facets of system administration. Kind of. Since only root
can grant, you still can't have a delegated user create and assign
namespaces to other users, but this is a step towards a decentralized
authorization model.
On Dec 5, 2013 5:02 PM, "John Vines" <[EMAIL PROTECTED]> wrote:

> There is some discussion about whether or not namespace should have a
> CREATE permission. This is stemming from just having name space permissions
> BE tablepermissions, and having their functionality extend to the namespace
> if approrpriate. That is, ALTER_TABLE can also be used to alter a
> namespace, drop_table can be used to drop the namespace, etc. However,
> there is no create in table and there's some discussion around that -
>
> <vines> Basically, I don't think we need NamespacePermissions
> <ctubbsii> Well, there's ALTER_NAMESPACE, CREATE_TABLE, and DROP_TABLE that
> seem to be useful.
> <ctubbsii> ALTER_NAMESPACE I suppose isn't needed.
> <ctubbsii> But, CREATE_TABLE and DROP_TABLE are still kind of useful, if
> they allow only within that namespace.
> <vines> TablePermission already has DROP_TABLE
> <vines> And ALTER could be applied for altering a namespace
> <vines> CREATE's the only iffy one
> <vines> Simply because I question if table creation, regardless of
> namespace, is something we want to have for people who don't have hte
> system permission
> <vines> Because restricting that permission is to prevent table's from
> being created, period. Not creating a table with a specific name
> <ctubbsii> Well, one of the goals was to be able to give full access within
> a namespace without the system permission.
> <ctubbsii> We kind of need create for that... but you could add it to
> TablePerms.... and it just has that special meaning.
> <ctubbsii> (where it would only get set on namespaces, but not tables...
> where it would be meaningless).
> <ctubbsii> If you want to drop it, too, that's fine with me. Either
> solution (move create to tableperms, or drop it) would work for me, until I
> get a chance to implement the pluggable operations-based security policy I
> described on RB (and I think I made a ticket, too).
>
>
> What is the communities thoughts?
>