Yep, I think Josh is correct. System permissions override Namespace permissions (so giving them System.CREATE_TABLE lets them create tables in any namespace) and Namespace permissions override any individual Table permissions. (at least that's how I implemented it originally, I don't think the permissions model would've changed much since then).
Sean On 08/15/2014 05:51 PM, Josh Elser 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>
