hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-13336) Consistent rules for security meta table protections
Date Tue, 13 Oct 2015 20:49:07 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955631#comment-14955631
] 

Andrew Purtell edited comment on HBASE-13336 at 10/13/15 8:49 PM:
------------------------------------------------------------------

bq. As it seems to be intended in this patch (and what looks logical), we want to have each
of 2 controllers (AC and VC) to cross-check both security tables, right?

Hmm.. I think it has to be done in core code, since neither AC nor VC should know the internals
of the other. Let's look at this instead as applying consistent protections to meta tables
in general, anything in the  'hbase:' namespace.

- Allow adding columns, but only if superuser.
- Allow modifying column or table descriptor attributes, but only if superuser.
- Disallow column and table drops, unless the requester is a superuser. 
- Disallow table disable, unless the requester is a superuser. 
- Allow enable and other admin requests (flush, compaction, region move) only if superuser.

We could add a check for superuser privilege just after the point where we call the preXXX
coprocessor hook for the respective operation, but we would want to skip this check if the
coprocessor - somehow - indicates to us an authoritative decision was made (only the AC would
be in a position to do this currently). We don't have a provision for doing that yet. If we
can add one, then core code can know if the decision can be delegated. If a coprocessor didn't
handle it, we would throw an ADE if the user is not a superuser.


was (Author: apurtell):
bq. As it seems to be intended in this patch (and what looks logical), we want to have each
of 2 controllers (AC and VC) to cross-check both security tables, right?

Hmm.. I think it has to be done in core code, since neither AC nor VC should know the internals
of the other. Let's look at this instead as applying consistent protections to meta tables
in general, anything in the  'hbase:' namespace.

- Allow adding columns, but only if superuser.
- Allow modifying column or table descriptor attributes, but only if superuser.
- Disallow column and table drops, unless the requester is a superuser. 
- Disallow table disable, unless the requester is a superuser. 
- Allow enable and other admin requests (flush, compaction, region move) only if superuser.

We could add a check for superuser privilege just after the point where we call the preXXX
coprocessor hook for the respective operation, but we would want to skip this check if the
coprocessor - somehow - indicates to us an authoritative decision was made (only the AC would
be in a position to do this currently). We don't have a provision for doing that yet. If a
coprocessor didn't handle it, we would throw an ADE if the user is not a superuser.

> Consistent rules for security meta table protections
> ----------------------------------------------------
>
>                 Key: HBASE-13336
>                 URL: https://issues.apache.org/jira/browse/HBASE-13336
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>            Assignee: Mikhail Antonov
>             Fix For: 2.0.0, 1.3.0, 0.98.16
>
>         Attachments: HBASE-13336.patch, HBASE-13336_v2.patch
>
>
> The AccessController and VisibilityController do different things regarding protecting
their meta tables. The AC allows schema changes and disable/enable if the user has permission.
The VC unconditionally disallows all admin actions. Generally, bad things will happen if these
meta tables are damaged, disabled, or dropped. The likely outcome is random frequent (or constant)
server side op failures with nasty stack traces. On the other hand some things like column
family and table attribute changes can have valid use cases. We should have consistent and
sensible rules for protecting security meta tables.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message