Endless loop triggered after idle time has elapsed in the shell

[jmark99]

Describe the bug
There are two parts to this issue. If a user is in the shell and the idle time has elapsed, when returning to the shell a message is displayed indicating that re-authentication should occur. Assuming the password in accumulo-client.properties is correct, the shell automatically authenticates and things proceed as normal. In this situation, an updated message to the user would be sufficient.

But as a test to verify that re-authentication would be required if the password did not match, a test was performed where the password within accumulo-client.properties was altered after initial setup. In this situation, after the idle time has elapsed, entering a command in the shell immediately triggers an endless loop displaying a mixture of Invalid password messages along with exception messages. The user is never offered the opportunity to supply the correct authentication password.

The output on Ubuntu was similar to the following with the messages continuing indefinitely until the shell process was killed in another terminal window.

root@uno> whoami
Shell has been idle for too long. Please re-authenticate.
Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password
2023-06-14T13:29:15,880 [shell.Shell] ERROR:org.apache.accumulo.core.client.AccumuloException:  java.io.UncheckedIOException: java.nio.channels.ClosedByInterruptException                 
2023-06-14T13:29:15,880 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: java.io.UncheckedIOException: java.nio.channels.ClosedByInterruptException 
2023-06-14T13:29:15,880 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: java.io.UncheckedIOException: java.nio.channels.ClosedByInterruptException 
2023-06-14T13:29:15,880 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: java.io.UncheckedIOException: java.nio.channels.ClosedByInterruptException 
Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password. Invalid password.

Versions :

• Affected version(s) of this project: 2.1.x
• OS: Ubuntu and CentOs were tested
• Java 11

To Reproduce
Fluo-Uno was used to instantiate an instance of Accumulo-2.1.1

1. uno fetch accumulo
2. uno setup accumulo
3. Modify accumulo-2.1.1/conf/accumulo-client.properties such that the user password is incorrect.
4. accumulo shell -u root -p secret --auth-timeout 1
5. Wait greater than 60 seconds and then perform a shell command such as whoami
6. Endless loop should begin at that point.

Expected behavior
I would expect the shell to allow the user to input the correct password and continue using the shell in a normal manner.

[dlmarion]

I wonder if the endless loop was due to the password being wrong vs not being set
I wonder if this issue exists in 2.1.0 with an incorrect password set and authTimeout occurring

[ctubbsii]

I wonder if the endless loop was due to the password being wrong vs not being set I wonder if this issue exists in 2.1.0 with an incorrect password set and authTimeout occurring

Confirmed that was the case. It seems to me that any time after the first failure, whether we're using a client config file or not, it should revert to an interactive password prompt. If the credentials are bad in the client config file, it's never going to work and you should be prompted, and if it's bad when interactively prompted the first time, then the retry is also going to be an interactive prompt. So, in both cases after the first attempt, it should retry using an interactive prompt.

The message could still be cleaned up in the re-authentication case when using the client config file, though. It seems weird to ask the user to re-authenticate, only to automatically have it happen for them... at the very least, a subsequent message could be shown that says it was done using the client config file, so the user doesn't just see a request to re-authenticate, followed by no prompt to actually do so.

[EdColeman]

Can this be closed with #3726 ?

[jmark99]

Yes. Missed it when I merged #3726. Closing now.