accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser call with authorizations argument
Date Wed, 01 Aug 2012 03:56:35 GMT


John Vines commented on ACCUMULO-677:

Authorizations can be extremely sensitive, moreso than read access to any table I would say.
So you want the ability to keep the ability to alter them as segregated as possible, so you
can have administrative users who can still function without having the ability to mess with
users authorizations. The idea here is to have a administer who can go around creating accounts,
resetting passwords, etc. but doesn't have the permissions to mess with users authorizations.
That is, they don't have the permissions to grant access to data because their role is not
granting data access.

Personally, I think that there may be a case for a dedicated permission for doling out permissions,
perhaps restricted to only authorizations that user has (exception for root user), in order
to restrict users from messing around in data spaces they otherwise shouldn't be messing with.
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>                 Key: ACCUMULO-677
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.4.1, 1.4.2
>            Reporter: John Vines
>            Assignee: John Vines
>            Priority: Minor
>              Labels: acl, alter, api, create, permissions, security, user
>             Fix For: 1.5.0
> Creating a user depends on a different ACL than granting Authorizations. If the user
can do one, but not the other it will still create the user but float back an error. This
can be confusing to end users, so I think we should isolate createUser to just creating the
user. They can then be granted authorizations as need be.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message