Ahh, so the intent of Namespace.CREATE_TABLE is to allow a user to create tables within a namespace without System.CREATE_TABLE. I verified just giving the user Namespace.CREATE_TABLE let them make a table in my 'foo' namespace. My guess was that both permissions were required, but it looks like that's not the case.
Thanks! On Fri, Aug 15, 2014 at 8:51 PM, Josh Elser <[email protected]> wrote: > Looking at this, I'm guessing that System.CREATE_TABLE is overriding any > permissions on the namespace 'foo'. > > Because 'user' has the ability to create tables at the System level, I'm > guessing it trumps the lack of CREATE_TABLE for user on that namespace. > > Disclaimer: I haven't looked at the code to back up that guess. > > > On 8/15/14, 8:35 PM, Matthew Dailey wrote: > >> From a clean Accumulo 1.6.0 install, I created a new user, gave them >> System.CREATE_TABLE, and created a new namespace, but did not give that >> user any permissions to that namespace. However, I was then able to >> create a table under that namespace as the new user. >> >> Is there some default openness for namespaces? My use case is having a >> user able to make sandbox tables within their own personal namespace. >> >> Thanks, >> Matt >> >> P.S. Command dump follows: >> >> root@accumulo> createuser user >> root@accumulo> grant -u user -s System.CREATE_TABLE >> root@accumulo> createnamespace foo >> root@accumulo> user user >> >> user@accumulo> createtable foo.bar >> user@accumulo foo.bar> insert a b c d >> user@accumulo foo.bar> scan >> a b:c [] d >> user@accumulo foo.bar> userpermissions >> System permissions: System.CREATE_TABLE >> >> Namespace permissions (accumulo): Namespace.READ >> >> Table permissions (accumulo.metadata): Table.READ >> Table permissions (accumulo.root): Table.READ >> Table permissions (foo.bar): Table.READ, Table.WRITE, Table.BULK_IMPORT, >> Table.ALTER_TABLE, Table.GRANT, Table.DROP_TABLE >> user@accumulo foo.bar> >> >
