accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Berman <mber...@sqrrl.com>
Subject Re: Discussion on Namespace permissions
Date Thu, 05 Dec 2013 22:11:18 GMT
I think there's value in restricting table creation to a particular
namespace.  The application is different from restricting table creation
overall (which is about limiting resource consumption), but assuming you
don't have that concern, it seems useful to be able to keep particular
users in a limited domain.


On Thu, Dec 5, 2013 at 5:02 PM, John Vines <vines@apache.org> 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?
>

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