[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285791#comment-14285791
]
Anoop Sam John edited comment on HBASE-12745 at 1/21/15 4:13 PM:
-----------------------------------------------------------------
I was saying to do it this way
{code}
public boolean havingSystemAuth(byte[] user) throws IOException {
// Implementation for backward compatibility
if (this.superUsers.contains(Bytes.toString(user))) {
return true;
}
List<String> auths = this.getUserAuths(user, true);
if (LOG.isTraceEnabled()) {
LOG.trace("The auths for user " + Bytes.toString(user) + " are " + auths);
}
return auths.contains(SYSTEM_LABEL);
}
{code}
bq.In VisibilityContorller.checkCallingUserAuth(), we only call
havingSystemAuth(byte[] user).
Even if the VLS having havingSystemAuth(User), we won't consider and check
against group auths? That would not be correct. Can we call
havingSystemAuth(User) and fall back to havingSystemAuth(byte[]) in case the
latter not available in VLS?
Like this
{code}
private void checkCallingUserAuth() throws IOException {
if (!this.acOn) {
User user = VisibilityUtils.getActiveUser();
if (user == null) {
throw new IOException("Unable to retrieve calling user");
}
boolean havingSystemAuth = false;
try {
this.visibilityLabelService.getClass().getDeclaredMethod("havingSystemAuth",
new Class[] { User.class });
havingSystemAuth = this.visibilityLabelService.havingSystemAuth(user);
} catch (SecurityException e) {
// Just consider this as AccessDeniedException
} catch (NoSuchMethodException e) {
// VLS not having havingSystemAuth(User) method. Go with deprecated
havingSystemAuth(byte[])
// method invoke
havingSystemAuth =
this.visibilityLabelService.havingSystemAuth(Bytes.toBytes(user
.getShortName()));
}
if (!havingSystemAuth) {
throw new AccessDeniedException("User '" + user.getShortName()
+ "' is not authorized to perform this action.");
}
}
}
{code}
was (Author: anoop.hbase):
I was saying to do it this way
{code}
public boolean havingSystemAuth(byte[] user) throws IOException {
// Implementation for backward compatibility
if (this.superUsers.contains(Bytes.toString(user))) {
return true;
}
List<String> auths = this.getUserAuths(user, true);
if (LOG.isTraceEnabled()) {
LOG.trace("The auths for user " + Bytes.toString(user) + " are " + auths);
}
return auths.contains(SYSTEM_LABEL);
}
{code}
bq.In VisibilityContorller.checkCallingUserAuth(), we only call
havingSystemAuth(byte[] user).
Even if the VLS having havingSystemAuth(User), we won't consider and check
against group auths? That would not be correct. Can we call
havingSystemAuth(User) and fall back to havingSystemAuth(byte[]) in case the
latter not available in VLS?
> Visibility Labels: support visibility labels for user groups.
> --------------------------------------------------------------
>
> Key: HBASE-12745
> URL: https://issues.apache.org/jira/browse/HBASE-12745
> Project: HBase
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.0.0, 0.98.9, 0.99.2
> Reporter: Jerry He
> Assignee: Jerry He
> Fix For: 2.0.0
>
> Attachments: HBASE-12745-master-v1.patch,
> HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
> HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
> HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
> HBASE-12745-v7-0.98.patch, HBASE-12745-v7-branch1.patch
>
>
> The thinking is that we should support visibility labels to be associated
> with user groups.
> We will then be able grant visibility labels to a group in addition to
> individual users, which provides convenience and usability.
> We will use '@group' to denote a group name, as similarly done in
> AcccessController.
> For example,
> {code}
> set_auths '@group1', ['SECRET','PRIVATE']
> {code}
> {code}
> get_auth '@group1'
> {code}
> A user belonging to 'group1' will have all the visibility labels granted to
> 'group1'
> We'll also support super user groups as specified in hbase-site.xml.
> The code update will mainly be on the server side VisibilityLabelService
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
