Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Discussion on Namespace permissions
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?
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB