The idea for this all started with someone mentioning
it’d be good if there was some magic thing which did some SSH voodoo to get you a shell that the person on the other end could watch
So, I took a quick look around and noticed that Screen can already do multiuser sessions, which do exactly this. However, controlling the session requires writing commands to screen, which is both relatively complex for beginners and relatively slow if the remote user is typing in ‘rm -Rf *’ ;)
So, I created a wizard-like python script, which sets up a multiuser screen session and a simple one button GUI (using PyGTK) for allowing and disallowing the remote user access to the session. It also optionally creates a script which makes it easier for the remote user to attach to the session.
- The helper script creation process for the remote user does not check the user input and runs sudo. Even though the script warns the user, it’s still a potential security risk
- If the script is terminated unexpectedly, the screen session will stay alive, and will need to be closed manually before this script will work again
Resolving the issues?
Fixing the security issue would be just a matter of more work. However, the lingering screens are a whole different problem: I tried to find out a way to get the pid for the screen session, but failed to find a way to do this in python. This would have made the lingering screen sessions less harmful, as all the communication could have been done with <pid>.<session> instead of simply <session>, which it uses now. The subprocess.Popen object contains the pid of the launched process, but the actual screen session is a child of this process, and thus has a different pid. If anyone can point me toward a solution to this, it’d be greatly appreciated!