Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7C48511B4A for ; Sat, 16 Aug 2014 09:53:42 +0000 (UTC) Received: (qmail 53533 invoked by uid 500); 16 Aug 2014 09:53:42 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 53482 invoked by uid 500); 16 Aug 2014 09:53:42 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 53469 invoked by uid 99); 16 Aug 2014 09:53:42 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Aug 2014 09:53:42 +0000 Received: from localhost (HELO mail-la0-f43.google.com) (127.0.0.1) (smtp-auth username ctubbsii, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Aug 2014 09:53:41 +0000 Received: by mail-la0-f43.google.com with SMTP id gi9so518525lab.16 for ; Sat, 16 Aug 2014 02:53:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.247.11 with SMTP id ya11mr16038939lbc.28.1408182819787; Sat, 16 Aug 2014 02:53:39 -0700 (PDT) Received: by 10.114.186.8 with HTTP; Sat, 16 Aug 2014 02:53:39 -0700 (PDT) In-Reply-To: References: <53EEAAFE.9040601@gmail.com> Date: Sat, 16 Aug 2014 05:53:39 -0400 Message-ID: Subject: Re: 1.6.0: Namespace.CREATE_TABLE not enforced? From: Christopher To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=001a113471dcc09c170500bc1cc0 --001a113471dcc09c170500bc1cc0 Content-Type: text/plain; charset=UTF-8 Both are not required. The intention of Namespace.CREATE_TABLE is so you can grant the CREATE_TABLE permission to users working in a given namespace without giving them the system-wide permission. This behaves similarly to the Table.GRANT permission allowing a user to grant other permissions to that specific table, but not to other tables, but the System.GRANT permission can grant other permissions to any table. It's also analogous to the system-wide configuration properties, per-namespace properties that apply to all tables in a namespace, and per-table configuration properties that apply only to a table. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Aug 15, 2014 at 9:10 PM, Matthew Dailey wrote: > 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 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> >>> >> > --001a113471dcc09c170500bc1cc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Both are not required. The intention of Namespace.CREATE_T= ABLE is so you can grant the CREATE_TABLE permission to users working in a = given namespace without giving them the system-wide permission. This behave= s similarly to the Table.GRANT permission allowing a user to grant other pe= rmissions to that specific table, but not to other tables, but the System.G= RANT permission can grant other permissions to any table.

It's also analogous to the system-wide configuration properties, pe= r-namespace properties that apply to all tables in a namespace, and per-tab= le configuration properties that apply only to a table.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii=


On Fri, Aug 15, 2014 at 9:10 PM, Matthew= Dailey <matthew.dailey1@gmail.com> wrote:
Ahh, so the intent of Namespace.CREATE_TABLE is to al= low a user to create tables within a namespace without System.CREATE_TABLE.= =C2=A0 I verified just giving the user Namespace.CREATE_TABLE let them make= a table in my 'foo' namespace.=C2=A0 My guess was that both permis= sions were required, but it looks like that's not the case.

Thanks!


On Fri, Aug 15, 2014 = at 8:51 PM, Josh Elser <josh.elser@gmail.com> wrote:
Looking at this, I'm guessing that Syste= m.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 name= space.

Disclaimer: I haven't looked at the code to back up that guess.


On 8/15/14, 8:35 PM, Matthew Dailey wrote:
=C2=A0From a clean Accumulo 1.6.0 install, I created a new user, gave them<= br> System.CREATE_TABLE, and created a new namespace, but did not give that
user any permissions to that namespace.=C2=A0 However, I was then able to create a table under that namespace as the new user.

Is there some default openness for namespaces?=C2=A0 My use case is having = a
user able to make sandbox tables within their own personal namespace.

Thanks,
Matt

P.S.=C2=A0 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 []=C2=A0 =C2=A0 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>


--001a113471dcc09c170500bc1cc0--