You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "alerman (via GitHub)" <gi...@apache.org> on 2023/05/25 14:27:08 UTC
[GitHub] [accumulo] alerman opened a new issue, #3427: Unauthenticated user can see tables list
alerman opened a new issue, #3427:
URL: https://github.com/apache/accumulo/issues/3427
**Describe the bug**
Starting shell with a bad username/password combination, the user can see the tables list using the `tables` command and only recieves an error when trying to scan
**Versions (OS, Maven, Java, and others, as appropriate):**
- 2.1
- CentOs 7.5
**To Reproduce**
Steps to reproduce the behavior (or a link to an example repository that reproduces the problem):
1. Start shell with bad use/pass combination eg `accumulo shell -u notAUser -p whoCaresItsFake`
2. run `tables` command
3. See list of tables
**Expected behavior**
Either the user should be rejected when starting the shell, or when running the tables command before displaying output.
--
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: notifications-unsubscribe@accumulo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3427: Unauthenticated user can see tables list
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1564706970
What needs to be online to validate user identity? There may be distinction between authenticating as a user versus being able to authenticate with ZooKeeper. If the shell was modified to allow ZooKeeper operations without having a running cluster - such as set properties, ZooKeeper authentication is required - but user authentication may not be available.
Using unix ACLs to protect the configuration should stop a shell user from creating and authenticating as Accumulo to ZooKeeper.
While the original request seems simple, this discussion is showing that the issue should be evaluated deeper than just mimicking the previous behavior and then assuming that is offering any degree of protection. Ask a Jeep owner with a canvas top if they lock their doors.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3427: Unauthenticated user can see tables list
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563139556
For 1.10.x, the Shell returns BAD_CREDENTIALS when a bad username/password is supplied, then the Shell exits. It seems like the behavior here has changed. Maybe it changed in 2.0 and it's not a bug?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1564708535
> Option 1. That's all I was asking for in the first place and this entire discussion could have been avoided. I just want the shell to have the same behavior it had in 1.10, and the expected behavior when passing a bogus user/pass combination to any interface.
The change in behavior you observed ended up highlighting the issue with the stuff in ZK being exposed, which might be worth revisiting. So, it's probably best that we did have the full conversation :smiley_cat:
I created #3433 to do item 1 for 2.1.1, and #3434 to explore item 2 for the future.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii closed issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii closed issue #3427: Unauthenticated user can see tables list
URL: https://github.com/apache/accumulo/issues/3427
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3427: Unauthenticated user can see tables list
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563459529
With the 2.0 prop change, the properties removed world:read permissions and require authentication to access. Most other things in ZooKeeper are world:read, but are restricted from making changes.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] alerman commented on issue #3427: Unauthenticated user can see tables list
Posted by "alerman (via GitHub)" <gi...@apache.org>.
alerman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1564546336
The client should absolutely be chnaged to authenticate when contstructed so that the user gets denied without getting to the prompt.
Can you site one example where that is not the case that would support leaving it as is? Should I be able to type a non existent username into the linux login prompt and be able to read any world readable files?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1564663776
> The client should absolutely be chnaged to authenticate when contstructed so that the user gets denied without getting to the prompt.
That was a design mistake initially made in Connector that caused performance issues. We ended up working around it for the system user, but we changed that when implementing AccumuloClient, to avoid that problem. Having that creates weird concurrency issues also, like the client can be constructed and authenticates, but then the client stops working because the password was changed by another client instance. That can happen now, but adding the fast failure will give false confidence that the initial construction is doing something more than it is. That would also prevent valid use cases, like being able to construct a client in a client application that is scheduled to perform a task in the future... such a client should be able to be constructed while servers are offline, as long as the task they execute doesn't occur until the servers are online again.
So, I don't think we should change this behavior of AccumuloClient. The current behavior is more flexible and prevents performance issues that were previously seen.
However, we can change the behavior in the shell, since the shell is intended to be an interactive client application, and it is strange for the shell to not authenticate right away.
This is a separate issue from the listing of tables, though. Adding in authentication to the shell initialization (or even the AccumuloClient) would not prevent an unauthenticated user from viewing the tables. They could still bypass Accumulo client code to use ZK client code to do that.
>
> Can you site one example where that is not the case that would support leaving it as is? Should I be able to type a non existent username into the linux login prompt and be able to read any world readable files?
I don't think that's the right analogy. This is more like viewing the contents of a mounted drive. The fact that you're logging in is incidental to the viewer environment. You could mount a drive and view its contents using a password-protected computer, or a computer without a password. The issue isn't with the authentication in the viewer. It's with the exposure of the data in the drive. If you use zkCli.sh, you don't need to log in to Accumulo at all, and you can get all the same info.
As stated above, the performance issues, and the ability to pre-construct a client are the use cases for not authenticating AccumuloClient immediately. But that's a separate issue from the fact that ZK is world readable in the first place, or that the AccumuloClient implementation talks directly to ZK instead of going through an authenticated RPC endpoint to talk to an Accumulo service to get the info.
Steps we can take:
1. Add authentication to shell startup and any time the shell user switches to another user - can be done for 2.1.1
2. Consider locking down ZK table info and having AccumuloClient get the info via an authenticated RPC (can also look at other things in ZK that are world readable) - probably too disruptive of a design change for 2.1.x.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563390560
> The information in ZooKeeper where the table name is stored is world readable and should not be considered sensitive.
Could we lock that down easily?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563449242
> So it sounds like you are saying that the behavior changed at some point between 1.10 and 2.1 (maybe 2.0), and that this is the expected behavior.
It changed in 2.0. AccumuloClient intentionally never implemented the "fail fast" authentication check that ConnectorImpl did (and does still in 2.1). So, when the shell switched to use AccumuloClient instead of Connector, it stopped causing the error. The error wasn't with the retrieval of table info. It was with the initial construction of the shell. So, if there's a problem at all here, it's not with the shell... it's with the AccumuloClient API that doesn't require authentication for ZK read-only operations that work on the client side. AccumuloClient is just treating it the same way zkCli.sh would.
Put another way: it's what Ed said above: "The information in ZooKeeper where the table name is stored is world readable". This has always been the case. The user's observation of the change in shell behavior is only highlighting the pre-existing choice to not make table information private in ZK.
So no, this isn't exactly a bug. But, it does raise the question that is implied in the second part of Ed's comment. He said that this "should not be considered sensitive". If there is anything to be done here, it would be because we are now asking "should it be considered sensitive?" and have decided the answer is "yes". If that's the case, then we can change the API's implementation to get the information via an RPC call and we can lock down the ZK view so it can't be accessed publicly with zkCli.sh either. If, on the other hand, we answer "no", then there's probably nothing to do here, other than to make it clear that table (and namespace) names and count are not sensitive in the documentation.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3427: Unauthenticated user can see tables list
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563411866
> The change is that we no longer authenticate an AccumuloClient with the server, until you try to do some action with that client (Connector always authenticated every time you created it, and that was intentionally changed). Some client operations only need to talk to ZK, so no authentication is needed to do those actions in our public API. So, no error in the shell when the shell uses our public API to do that. To change that, we would need to replace some client side implementations with RPC calls to servers to do those actions for the client.
So it sounds like you are saying that the behavior changed at some point between 1.10 and 2.1 (maybe 2.0), and that this is the expected behavior.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3427: Unauthenticated user can see tables list
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563083510
Just for information.
The information in ZooKeeper where the table name is stored is world readable and should not be considered sensitive.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563395201
> For 1.10.x, the Shell returns BAD_CREDENTIALS when a bad username/password is supplied, then the Shell exits. It seems like the behavior here has changed. Maybe it changed in 2.0 and it's not a bug?
The change is that we no longer authenticate an AccumuloClient with the server, until you try to do some action with that client. Some client operations only need to talk to ZK, so no authentication is needed to do those actions in our public API. So, no error in the shell when the shell uses our public API to do that. To change that, we would need to replace some client side implementations with RPC calls to servers to do those actions for the client.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3427: Unauthenticated user can see tables list
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563156535
Carrying BAD_CREDENTIALS behavior forward seems the safest option unless someone can provide an explicit, legitimate reason for relaxing it.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3427: Unauthenticated user can see tables list
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1563452235
Also, although AccumuloClient does not authenticate when it is constructed. We could make the shell do that. That's a separate issue than the question about whether table names and quantity are sensitive in ZK.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] alerman commented on issue #3427: Unauthenticated user can see tables list
Posted by "alerman (via GitHub)" <gi...@apache.org>.
alerman commented on issue #3427:
URL: https://github.com/apache/accumulo/issues/3427#issuecomment-1564677147
Option 1. That's all I was asking for in the first place and this entire discussion could have been avoided. I just want the shell to have the same behavior it had in 1.10, and the expected behavior when passing a bogus user/pass combination to any interface.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org