Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow eventual scans of accumulo metadata and root tables #4528

Closed
ddanielr opened this issue May 6, 2024 · 4 comments · Fixed by #4531
Closed

Disallow eventual scans of accumulo metadata and root tables #4528

ddanielr opened this issue May 6, 2024 · 4 comments · Fixed by #4531
Assignees
Labels
enhancement This issue describes a new feature, improvement, or optimization.

Comments

@ddanielr
Copy link
Contributor

ddanielr commented May 6, 2024

Is your feature request related to a problem? Please describe.
Scans using an eventual consistency level should never be allowed to run against the accumulo namespace.
This is to ensure that data results loaded from the metadata table and root tables are always accurate and not out of date.
Inaccurate results being returned could lead to system failure if used for administration actions.

Describe the solution you'd like
Scanners using a consistency level of eventual should fail immediately when attempting to scan the accumulo. namespace. Likewise the scan servers should also fail client scans to the accumulo. namespace.

Describe alternatives you've considered
Handling the scan failure in the client is faster, but if a malicious client modifies the client jar, then the scan server still needs to handle additional failures.

Additional context
Because this is at a namespace level, it should be easier to have a simple deny rule then needing to keep track of any additional accumulo.tables that are added in future versions.

@ddanielr ddanielr added the enhancement This issue describes a new feature, improvement, or optimization. label May 6, 2024
@ddanielr ddanielr added this to To do in 3.1.0 via automation May 6, 2024
@ddanielr ddanielr added this to To do in 2.1.3 via automation May 6, 2024
@dlmarion
Copy link
Contributor

dlmarion commented May 7, 2024

Do we want to preclude users from being able to perform eventual scans on these tables? Just wondering if there is a use-case where this is needed and whether or not it could be enforced that eventual scans on the accumulo namespace are not allowed from within the server processes and utilities.

@ddanielr
Copy link
Contributor Author

ddanielr commented May 7, 2024

@keith-turner brought up that maybe we want to block this for all users except the system user.
We might have a valid use-case for certain utility functions in accumulo that produce reports or metrics for troubleshooting that would run as the system user.

@cshannon
Copy link
Contributor

cshannon commented May 10, 2024

This only applies to elasticity, but would we also want to disallow eventual scans on the new FATE table that is now part of the accumulo namespace?

@dlmarion dlmarion self-assigned this May 20, 2024
3.1.0 automation moved this from To do to Done May 20, 2024
2.1.3 automation moved this from To do to Done May 20, 2024
@dlmarion
Copy link
Contributor

This only applies to elasticity, but would we also want to disallow eventual scans on the new FATE table that is now part of the accumulo namespace?

I took care of this in elasticity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This issue describes a new feature, improvement, or optimization.
Projects
2.1.3
Done
3.1.0
Done
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants