[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170069#comment-16170069
]
Ankit Singhal commented on PHOENIX-4198:
----------------------------------------
Thanks [~apurtell],[~elserj],[~tdsilva],[~sergey.soldatov] for the comments.
bq. Make sure to add a JUnit Category annotation to TableDDLPermissionsIT
otherwise you'll run into PHOENIX-4191. Does it make sense to consolidate that
test with SystemTablePermissionsIT?
Annotated with a category for now. Yes, we probably can remove
SystemTablePermissionsIT now.
bq. mutateRowsWithLocks(...) seems a little weird – when we're doing the new
code-path, we don't explicitly grab any locks whereas I'd assume that does
happen in the other codepath. Is that OK?
Actually, if ACL access is not enabled, we do it with the earlier
logic(region.mutateRowsWithLocks) where region server acquiring read locks
again during mutation. Not sure why we had required this with a single region
of the system.catalog table as we were already taking lock before, does it
ensure that all rows are written atomically which Htable.batch will not? are
there any consequences of writing set of mutations with HTable.Batch which is
not there in region.mutateRowsWithLocks?
bq. but mandating them is IMHO mandating user lock-in on something external to
HBase+Phoenix for what is a core functional concern (protection of SYSTEM
tables)
Yes [~apurtell], as [~elserj] also clear my point that we are not making
Phoenix dependent on any third party component for access control for DDLs
operation. The purpose is just to use the right set of public API so that
third-party component can also work automatically in future along with HBase
Native access control if they implement the APIs required for it.
bq. I believe he did some legwork to realize that one of these third-party
components didn't actually implement the full interface, and would thus not
actually work. I'll let Ankit confirm, but I think you are of the same opinion
that I am – Ranger (or Sentry) not implementing the full interface is not our
problem and not something we should care about.
yes, Ranger or Sentry will not work until they implement the
AccessControlService.Interface#getUserPermissions API
bq. Thinking about this more, even if we use this approach to not require that
a user has write access to SYSTEM.SEQUENCE a user can still access any sequence
by using SELECT NEXT VALUE for, so maybe that should be addressed separately.
Yes, We may need to take it in separate JIRA, as we need to treat sequences as
another entity which currently doesn't exist in HBase
bq. Are the changes in MetadataEndpointImpl that use LockManager required
because even if you run as the HBase user calling region.mutateRowsWithLock
still uses the original user context ?
Yes [~tdsilva] that's why we need to create a new RPC using HTable to change
the user context.
bq. In QueryServicesOptions.java there is a new import of
net.sf.ehcache.config.TerracottaConfiguration.Consistency. Is it incorrect IDE
autoimport ?
[~sergey soldatov], removed from newer version
> Remove the need for users to have access to the Phoenix SYSTEM tables to
> create tables
> --------------------------------------------------------------------------------------
>
> Key: PHOENIX-4198
> URL: https://issues.apache.org/jira/browse/PHOENIX-4198
> Project: Phoenix
> Issue Type: Bug
> Reporter: Ankit Singhal
> Assignee: Ankit Singhal
> Labels: namespaces
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4198.patch
>
>
> Problem statement:-
> A user who doesn't have access to a table should also not be able to modify
> Phoenix Metadata. Currently, every user required to have a write permission
> to SYSTEM tables which is a security concern as they can
> create/alter/drop/corrupt meta data of any other table without proper access
> to the corresponding physical tables.
> [~devaraj] recommended a solution as below.
> 1. A coprocessor endpoint would be implemented and all write accesses to the
> catalog table would have to necessarily go through that. The 'hbase' user
> would own that table. Today, there is MetaDataEndpointImpl that's run on the
> RS where the catalog is hosted, and that could be enhanced to serve the
> purpose we need.
> 2. The regionserver hosting the catalog table would do the needful for all
> catalog updates - creating the mutations as needed, that is.
> 3. The coprocessor endpoint could use Ranger to do necessary authorization
> checks before updating the catalog table. So for example, if a user doesn't
> have authorization to create a table in a certain namespace, or update the
> schema, etc., it can reject such requests outright. Only after successful
> validations, does it perform the operations (physical operations to do with
> creating the table, and updating the catalog table with the necessary
> mutations).
> 4. In essence, the code that implements dealing with DDLs, would be hosted in
> the catalog table endpoint. The client code would be really thin, and it
> would just invoke the endpoint with the necessary info. The additional thing
> that needs to be done in the endpoint is the validation of authorization to
> prevent unauthorized users from making changes to someone else's
> tables/schemas/etc. For example, one should be able to create a view on a
> table if he has read access on the base table. That mutation on the catalog
> table would be permitted. For changing the schema (adding a new column for
> example), the said user would need write permission on the table... etc etc.
> Thanks [~elserj] for the write-up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
