Shadowers have the same input control as the original user. When a shadower is connected, and either the shadower or the original user, is dragging a window. The other user cannot interfere while the first user is dragging. Control of mouse input is locked to one client while a mouse button is down. The system was designed this way to ensure a sane user experience. However, this design has one problem; if the client that currently has control of the pointer disconnects, input for the other client is locked for a very long time. Allegedly, it releases after ~10 minutes, but I haven't verified that. Steps to reproduce: 1. Configure your server to have at least two users 2. Add at least one of them to '/shadowing/allowed_shadowers' 3. Log in to ThinLinc from a client on a VM where you can control the network connection 4. Start `glxgears` to show continuous graphical updates and have a window to that can be dragged. 5. Find a colleague to help you 6. Ask your colleague to open a second ThinLinc client and connect as a shadower 7. Start dragging the `glxgears` window in the first client 8. While dragging, ask your colleague to disable the network connection on the VM running the first client 9. In the second client, note that input (both keyboard and mouse) are blocked. Also note that you still get graphical updates.
This has been resolved upstream in TigerVNC: https://github.com/TigerVNC/tigervnc/pull/1718
It probably doesn't matter if the shadower or the original user disconnects. Note however that we have only tested disconnecting the original user.
To clarify, the issue is actually not about disconnects. If either client disconnects, then everything works just fine. The issue is when either client hangs. Either because the software has locked up, or because the network abruptly stops working. You can easily simulate this by sending a SIGSTOP to a client's ssh process.
Verified that I could see the issue with ThinLinc 4.18.0 on RHEL 10 beta. Tried stopping both the regular client, and the shadowing. After upgrading to build 3926, control is returned to the other client after a few seconds. Again, tested both the regular and shadowing client.
All done. > MUST: > > * If the client for a shadower or regular user stops communicating with the server, the remaining connected user should have full control over the input in the session Indeed, after a bit of a delay. The delay can be annoyingly long, but the trade-off was to avoid false triggers. An unresponsive client should hopefully be rare, so I think this is a good compromise.
