butler@BRL.MIL ("Lee A. Butler") (03/13/90)
First off I would like to thank everyone (especially those at SGI) who offered help/explanations/appologies to my message on the problems with the program examples in the manuals. Now I have some new questions and a few nits to pick. Appologies to all if these have been discussed before. If I've missed a manual page somewhere, please let me know. 1) /dev/console (seems to be mode "20622" (also "crw--w--w-") as delivered. Might this pose some (minor?) security problems? chmod'ing it to '20600' seems to "stick". Other tty's seem to have similar conditions. Is this really the way a system should be configured? 2) The ownership of /dev/console seems to shift in bizzare ways. Sometimes when I log in (on the console) it is owned by me and sometimes by some other user or "root". 3) Perhaps related to the previous two items, it is possible for another user to open a window on the graphics display while I am using the window manager on the console. This becomes nasty when the program that other user runs is something like a "screen lock" program! Is there something that applications could check to reliably determine whether or not they should access the console? Better still, is there any way of enforcing console access to the user running 4sight/window-manager? 4) It would appear that there may be a minor problem with the keyboard or the keyboard handling routines on the Personal Iris. I was writing an application for the Iris and using "qread" to process keyboard (as well as other) input. One of my robustness tests was to rake my hands accross the keyboard in an attempt to overflow input buffers or find faults in the input handling. What I found was that keys would somehow become re-mapped. A bit of study leads me to believe that I was getting something akin to "alt-lock" and/or "control-lock." I speculate that whatever is processing the keystrokes was getting a "control-key-pressed" event, but missing the "control-key-released" event. Since it never got another "released" event without first, getting a "pressed" event, that key would never become fully "released". It is interesting to note that I was unable to duplicate the problem on a 4D/240. Comments? Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066