de5@ornl.gov (Dave Sill) (01/18/91)
I'm curious about the current state of display access control in X and predicted future developments. I'd appreciate any information on this topic beyond what's included in the X11R4 man pages, including answers to these questions: What access control mechanisms are part of the X protocol? I'm sure that the hostwise mechanism is, but was magic-cookie authorization added with R4? Did the X protocol change between R3 and R4? If we can't expect to be able to use DES-, RSA-, or Kerberos-based magic cookies at some point, is there any hope of a general mechanism for controlling access with more granularity than "anyone on host A can do whatever they want with my display"? Would it be possible to wrap access control around the server somehow? E.g., could one construct a client that would tell me when someone accesses my display, or even allow me to grant or deny access on a case-by-case basis? Is there any chance that we might one day be able to control access to individual windows in a manner similar to the way access to files is controlled under UNIX, VMS, or any other multiuser OS? I.e., read/modify/delete bits for owner and others, at least, or even access control lists. Is anybody running, or planning to run, X in a DoD-type classified environment? If so, how? What vendor-specific access-control mechanisms are available or planned? Thanks in advance. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.
mouse@lightning.mcrcim.mcgill.EDU (01/24/91)
> I'm curious about the current state of display access control in X > and predicted future developments. [...] > What access control mechanisms are part of the X protocol? From the protocol document: 8. Connection Setup For remote clients, the X protocol can be built on top of any reliable byte stream. The client must send an initial byte of data to identify the byte order to be employed. [...] Following the byte-order byte, the client sends the following information at connection setup: protocol-major-version: CARD16 protocol-minor-version: CARD16 authorization-protocol-name: STRING8 authorization-protocol-data: STRING8 [...] The authorization name indicates what authorization protocol the client expects the server to use, and the data is specific to that protocol. Specification of valid authorization mechanisms is not part of the core X protocol. It is hoped that eventually one authorization protocol will be agreed upon. In the meantime, a server that implements a different protocol than the client expects or that only implements the host-based mechanism may simply ignore this information. If both name and data strings are empty, this is to be interpreted as ``no explicit authorization.'' The server, of course, will usually be able to determine what host the connection attempt is coming from. > Would it be possible to wrap access control around the server > somehow? E.g., could one construct a client that would tell me when > someone accesses my display, or even allow me to grant or deny access > on a case-by-case basis? Strictly speaking, no. However, something very similar can be done quite easily. All you need to do is to write a small program which listens for X connections. When it gets one, it reads the initial data sent by the client, which includes the authentication information. Based on this it can do whatever it likes, including interacting with the real X server to ask the user for confirmation. If it decides to deny the connection, it generates a "denied" response and drops the connection. If it decides to accept it, it connects to the real server, sends over whatever is necessary to persuade the server to speak to it, and then starts just forwarding bytes between the client and the real server. You pay a speed penalty for this, of course; every byte has to be handled by another program, with all that implies. However, based on similar things I have done, I believe the speed penalty is typically small enough to be ignorable. And it has the advantage (a big one, in some environments) that you can do pretty much whatever you please in the way of authentication and confirmation by the user. You could even keep some sort of permanent object on the screen corresponding to the connection in case the user wants to shut it down. (Note that window-manager-type protocol requests don't allow shutting down connections which haven't created any resources, for example a program designed to spy on keystrokes.) > Is there any chance that we might one day be able to control access > to individual windows in a manner similar to the way access to files > is controlled under UNIX, VMS, or any other multiuser OS? There is nothing conceptually difficult about this. But don't ask *me* to write the code :-) It could be a useful extension. I'd like to see something of the sort tried, even though I suspect I wouldn't use it much myself. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu