See:

• About These Pages
• X Server Modification Project, Bug 43

Contents

Notes

• Yesterday, I wrote to Hans-Bernhard Broeker with a question about whether Cscope can handle functions called by function pointers. His answer is basically "no", but I probably will want to reread his answer more than once — I think there are important "clues" throughout his answer. His entire answer is quoted on Cscope.

• Update on possible approaches: (Yesterday I outlined the three possible approaches I saw to the problem (intercepting keyboard events between the keyboard and xserver, in the xserver, or between the x server and the client) and the pros and cons of each. I realize that left out some other possibilities which I will list here (with little discussion) for the sake of completeness (the first three below are really just an expansion of "intercepting keyboard events between the keyboard and xserver"). Intercept keyboard events:
  • (interrupts) before they get to the kernel (is it possible?)
  • (interrupts) within the kernel (with a kernel module)
  • as they are passed from the kernel to the X server
  • in the X server
  • between the X server and the client --> near the X server, so one module handles all clients
  • between the X server and the client --> near the X clients, so there is a module for each X client
  • in the X clients (thus modifications are required in each X client)

After a little thought (perhaps very little), I think dealing with the problem in the X server might be the most "elegant solution" in a few senses (if you are coming late, some of the following builds on earlier findings and discussion, including attempts to use tools like gtkeyboard (similar to xvkbd):

• I should be able to deal with the fewest number of events there — not the up to six (interrupt) events from each press of a key, nor have to worry about relaying all events (mouse, keyboard, display) between the X client and X server.
• Dealing with the one or two events per keypress in the X server as keycodes (keysyms, or whatever the X client needs) sounds easier than dealing with raw key codes earlier in the data path.
• It will work with any X application -- it won't have the problems gtkeyboard has with, for example, Mozilla and kde applications.
• Unfortunately, it will require modifications to all X servers — it will not work with, for example xfree86 3.3.6, 4.0., ..., etc. unless someone goes back to modify those. (However, if I do develop a patch for say 4.3.n, the patch might be fairly easy to modify for versions back through 3.3.6, on the assumption that the code in this area of the X server may not have changed much over that period of time.)

Based on the above, and despite the objections to making such a change in the X server (by some of the X developers), I will probably continue to work towards a solution in the X server (but maybe with more vigor after Wednesday).

Although that is only a tentative decision, I should dig into the security aspects before finalizing such a decision. The one objection I've heard expressed as has been to the idea that someone might make one of your keyboard macros do something like rm -r / (or whatever). Some things (I can think of) to consider:

• Who can take control of your (physical) keyboard, and under what circumstances?
  • I would want to continue to allow remote X access, at least for myself. If I allow this, does the keyboard macro facility significantly increase the risk? I don't think so -- if someone else gets control of my keyboard they can do rm -r / with or without the keyboard macro facility -- maybe just a little faster with the macro facility. I need to depend on other defenses against things like that — keep my system secure (things like use ssh instead of telnet or "plain" X forwarding, NAT and firewalls, command aliases (like rm -i) or would something disable the alias feature because I'd be in a different shell or something? I don't think so — this is one of the advantages of modifying the X server so the "simulated" keystrokes look just like ordinary keystrokes.
• I probably want to keep the macro definitions in a very secure file so they can't be tampered with (consider things like having rw access only for the user)
• <other?>
• Maybe the other security issue is just the idea of providing another set of pitfalls for others if they don't take sufficient security precautions?

Contributors

• () RandyKramer - 14 Apr 2003
• If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.

Page Ratings