ctubbsii opened a new issue, #6123:
URL: https://github.com/apache/accumulo/issues/6123

   Scan servers can be organized by administrators into separate resource 
groups to allocate specific server-side resources for specific table scans. 
However, this relies on a lot of trust that the user is responsibly using scan 
servers that are allocated by an administrator for those scans. That is because 
the selection process is done by a ScanServerSelector, which is a client-side 
plugin. It is possible that a user could use a ScanServerSelector that behaves 
irresponsibly and abuses server-side resources allocated for others.
   
   There are several ways a system administrator could restrict a scan from 
operating on a particular scan server:
   
   * restrict the users allowed to request a scan on a scan server
   * restrict the iterators, classloader context, or other scan configuration, 
that is allowed to execute on the scan server
   * restrict the tables allowed to be scanned on a scan server
   
   For restricting users, we already have permissions to decide whether a user 
has permission to scan particular data. In this case, for resource utilization, 
it isn't really important who is doing the scan, but which table they are 
scanning, since the table's data determines how much resources are used.
   
   For restricting iterators, classloader context, etc., the administrator can 
already restrict those things by controlling the ContextClassLoaderFactory or 
the configuration, so it's not necessary to do anything else for that.
   
   That leaves restricting based on tables. We should add a new property for 
scan servers that represents the allowed set of tables that a scan server can 
scan. If a table doesn't match this, then it could throw a security exception. 
This property by default could be `.*`, but could be further restricted to 
something like `(namespace1|namespace2)[.].*`, and configured differently for 
different resource groups, if the administrator so chose.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to