Thanks for the information. Just as a side note: this is critical to use Phoenix in larger organizations, so for it's worth, I vote +1 for this effort. Good on you.
On Mon, Oct 23, 2017 at 12:25 PM, Andrew Purtell <[email protected]> wrote: > There is some work in progress* to make it so only global read privilege on > some SYSTEM tables will be necessary for clients to continue to function > normally for DML operations. For DDL operations, the embedded Phoenix > metadata service (MetaDataEndpoint) will modify system tables on behalf of a > suitably privileged user and also drive standard HBase namespace and table > administrative actions. Related, Phoenix needs to adopt a permissions model > and grant management syntax. > > * - See PHOENIX-672 and PHOENIX-4198 for two examples. > > > On Mon, Oct 23, 2017 at 12:38 AM, Ankit Singhal <[email protected]> > wrote: >> >> bq. But for tables inside, I am assuming the user needs access to the >> >> Phoenix SYSTEM tables (and CREATE rights for the namespace in questio >> n >> >> on the HBase level)? Is that the case? And if so, what are they able >> to see, as in, only their information, or all information from other >> tenants as well? If so, is there a way to truly isolate them? >> >> Currently, a Phoenix user requires RWCXA on SYSTEM tables, thus, they will >> be able to see all the schemas and tables for all the tenants by simply >> running a query against SYSTEM.CATALOG . In order to restrict access against >> the underlying HBase ACLs, We may need to bring some cell level ACLs or >> control all access to system tables by some end point having access >> controller checks(like we do for HBase acl table). >> >> >> On Mon, Oct 23, 2017 at 6:15 AM, Ethan Wang <[email protected]> wrote: >>> >>> !schema sounds like a great idea. For users who has permission to see, to >>> list all the visible schemas. >>> >>> >>> On October 22, 2017 at 1:07:58 AM, Lars George ([email protected]) >>> wrote: >>> >>> Hi, >>> >>> I am wondering, in a secured cluster with Kerberos and HBase ACLs, and >>> with namespace mapping enabled in Phoenix, what is needed to enable >>> users to create their own tables in a "schema"? The documentation >>> >>> (https://phoenix.apache.org/namspace_mapping.html#What_permissions_are_required_to_CREATE_and_DROP_SCHEMA) >>> states that you need admin permissions in HBase to create the schema, >>> which makes sense as it creates a namespace in HBase. >>> >>> But for tables inside, I am assuming the user needs access to the >>> Phoenix SYSTEM tables (and CREATE rights for the namespace in question >>> on the HBase level)? Is that the case? And if so, what are they able >>> to see, as in, only their information, or all information from other >>> tenants as well? If so, is there a way to truly isolate them? >>> >>> Oh, and I was wondering why there is no "!schema" or some such. Or am >>> I missing something? >>> >>> Cheers, >>> Lars >> >> > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk
