On Fri, Oct 23, 2009 at 06:55:35AM -0500, Chris Brannon wrote: > > although the question is still who the current user is. I > > would define the current user as the one who is using Speakup at the > > time that text is copied to the Speakup clipboard. > > That is a perfect definition! How do you determine who the current user is? > I looked at headers under /usr/src/linux/include yesterday, and there > doesn't seem to be any sort of userid field associated with the C structs > that represent virtual consoles. Right, I don't believe the kernel has anything to do with managing users/groups/logins/logouts other than enforcing permissions. It manages the virtual terminals, but it doesn't seem to know or care who is using them. > I suppose that you could use the number of the virtual console on which > the copy / paste operation is being performed. Even if you know this, I don't know of a way you can tell from the kernel who is logged onto that virtual terminal. > Next, you have to figure out how to contact the X server that the current > user is using. > > If there is going to be any sort of automatic transfer of data between > Speakup's cut buffer and the X clipboard, then both of those pieces > of info need to be known. Who requested the copy or paste, and where is > his X server -- assuming that he is running X? The only way I can think of to get the user's X server (assuming you know who the user is), would be to get into his environment and check the DISPLAY environment variable he has set. But, I have no idea how this could be done. > > Another idea would be to require a user to be in a special group, > > similar to only making the CD drive accessible to users in the "audio" > > group. The group would have to manually be created > > This is a really good idea, for everything under /sys/accessibility/speakup. > The group would be created by the person who packages Speakup for your distro. > The file ownerships need to be set correctly whenever speakup's modules are > loaded. If you look at "man modprobe.conf", there's a description of > something called "install". This "install" primitive allows us to run > arbitrary commands whilst loading a module. > The people who package Speakup could probably do all of this today, without > requiring any change to the Speakup code. > This won't solve all the problems related to automatic export / import > of the clipboard, though. Right, securing speakup's /sys files, in general, is a completely separate subject imho. I do agree though that this would be best handled in user space without doing anything to the speakup code. William
