These could be better documented. It's been awhile since I've thought about these, but I think:
SystemPermission.SYSTEM - basically permits superuser access to perform most operations. However, this does not allow automatic access to tables. A user with this permission, however, can grant themselves permissions to do so. SystemPermission.GRANT - this is a special permission that allows the bearer to grant system permissions to other users. This supports the case where an admin user is granted system permission, but is not allowed to share those elevated privileges with other users. At one point, I think this permission could not be granted... so only the root user could have this, but I think it can be granted now... but it must be done so explicitly... either way, the important bit is that it doesn't come with the SYSTEM permission automatically. SystemPermission.OBTAIN_DELEGATION_TOKEN - that's a special permission that allows the user to request delegation tokens, which are time-limited alternatives to Kerberos credentials when you need to perform an operation... like MapReduce... across a cluster, and don't want to (or can't) share your user's authentication credentials. This is because you probably don't want to share your keytab everywhere, or run kinit interactively on each MapReduce node in a cluster, in order to run a MapReduce job. Because these allow impersonation of the requesting user, they are time-limited, and require explicit permission to obtain. For your scenario, the root user is already set up that way. You could create another user and grant them SYSTEM permissions to do the same. However, any user you create with SYSTEM permissions will be able to grant themselves READ and/or WRITE permission on any table they like. If you need more fine-grained access controls, you could plug in your own `instance.security.permissionHandler`, but that pluggable component predates our attempt to create stable SPI endpoints, so it might not be a stable interface, and you may need to update it for new releases. Stabilizing that as a proper SPI is a medium term goal of mine, personally, but I'm not sure when it will happen. On Thu, Dec 15, 2022 at 1:56 PM Logan Jones <[email protected]> wrote: > > Hello: > > I'm working on updating our security posture for our various Accumulo > users. I took a look at the Permissions Page > <https://accumulo.apache.org/docs/2.x/security/permissions> along with the > Java docs for SystemPermission > <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/SystemPermission.html> > , NamespacePermission > <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/NamespacePermission.html>, > and TablePermission > <https://www.javadoc.io/doc/org.apache.accumulo/accumulo-core/latest/org/apache/accumulo/core/security/TablePermission.html> > but > still have some questions. Specifically, I would like to know what the > following Permissions are used for: > > > - SystemPermssion.GRANT - My assumption is that this means a user with > these permissions can grant other users various system permissions. > Effectively if you have this permission you have the ability to have all > other system permissions. > - SystemPermission.SYSTEM > - SystemPermission.OBTAIN_DELEGATION_TOKEN > > Also, I'd be interested in your opinions on what permissions I should set > up for the following scenario. I would like to create a root user that can > only manage user/authorizations but cannot read data from any tables, the > root user would be responsible for creating application users which can do > everything but create users and alter authorizations. What permissions > should I set up to make that happen? > > Thanks, > > - Logan
