alan@arc.UUCP (Alan Mimms) (01/09/88)
Why the devil isn't the strange behavior of events queued by XSendEvent (rather than the usual way) more loudly proclaimed in the manuals? XSendEvent sets the high-order bit in the event type code! This is bad since there is no way to disable this "feature" should one wish to use one client to cause events in another client. I suppose it is reasonable to provide a way to discern events directly from the server and events that were artifically generated, but couldn't it be either (a) optional (good) or (b) invisible unless you explicitly look for it (better)? I wonder if maybe it would be prudent to make this "feature" optional? Is there such a hook? We're presently getting around this by hacking clients to mask the event type with 0x7F before they use the value or by making a call to XESetWireToEvent to register a routine which makes a teeny change in the event after it's converted. Any thoughts? Can we hear some pro/con discussion? (Or better yet, will it "be fixed in the next release"?) Alan Mimms ...!sun!texsun!arc!alan ADVANSOFT Research Corp. 4301 Great America Pkwy Santa Clara, CA 95054 (408) 727-3357
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (01/12/88)
This has been a topic of discussion on xtensions. There is a proposal to move the high bit into a separate boolean flag in the event structure. I expect an MIT X Consortium group will deal with this issue in the very near future, and it will probably be "fixed in next release".
deboor@dill.Berkeley.EDU.berkeley.edu (Adam R de Boor) (01/13/88)
The main Good Reason for XSendEvent to set the high bit is to forestall fraud (this is something I was going to mention when the Siemens folks brought it up, but it didn't seem that important at the time). Imagine, if you will, an xterm window, perhaps running a root shell, and a malicious person (who, perhaps, identifies the correct window by looking for a descriptive name like "Root Shell") who sends a string of KeyPress and KeyRelease events to the window to get it to do things... Masking the high bit off is harmless for most applications, but there are a few where it causes a potentially-serious security breach. Perhaps the event translation manager could be made to mask the high bit upon request... a
guido@cwi.nl (Guido van Rossum) (01/13/88)
>The main Good Reason for XSendEvent to set the high bit is to forestall >fraud... Hmm, it would seem that there are enough other fraudulent things you can do to a user once you've gotten access to the display she's using. Setting the high bit on event types can only give a false feeling of security. A different form of security is that of program correctness: there are cases where the server guarantees that particular events will or won't be sent, or will be sent in a particular order. Applications may rely on this. Events inserted at random points in the event stream by other clients may spoil the assumptions. However, even here (as everywhere else) I'd prefer "trust, but check". -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or (from ARPAnet) guido%cwi.nl@uunet.uu.net