If a user logs on remotely using ssh the DISPLAY environment variable
is set automatically to e.g. remote:1.0. [This assumes X forwarding is
set for sshd.]
Now in this situation, SunPC does not work, typing at the local keyboard
does not show up in the sunpc window. (The solution is to:
setenv DISPLAY local:0.0
before running sunpc).
However what does happen is that when the sunpc window has focus from
the local mouse, anything typed at the remote keyboard (i.e. the
keyboard attached to the CPU on which the sunpc executable is running)
appears in the sunpc window. In particular, if the remote system is
awaiting an xdm login, then the username and password show up in the
local user's sunpc window.
Further, if sunpc is instructed to attach the mouse 'internally', it
takes control of the remote mouse!
Now the sunpc executable is not suid, and the appropriate remote devices
(/devices/pseudo/cons*) are always mode 600. It appears that the sunpc
executable is somehow using the DISPLAY environment variable to
determine which keyboard and mouse to use. Also though there must be
some flawed mechanism by which authority to read the keyboard and mouse
are obtained.
Our short-term solution is to use the xdm login mechanism to change the
permissions on /dev/sdos* so that only the local user may run sunpc. We
didn't want to turn off X forwarding, as that reduces the value of ssh.
Has anybody seen this before. More importantly, is there any useful
workaround?
Ray Brownrigg
School of Mathematical and Computing Sciences
Victoria University of Wellington