accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <>
Subject Discussion on Namespace permissions
Date Thu, 05 Dec 2013 22:02:01 GMT
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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message