On 12 April 2011 21:04, Iskren Chernev <iskren.cher...@gmail.com> wrote: > I don't think this lengthy discussion led to any concrete answers, but I do > think that the questions are important and need such answers. > I'll try to summarize the problems that need attention: > 1. screen locking > 1.1 who is going to implement it: compositor/compositor plugin/app
The problem is that "screen locking" is in fact several generic things in one. While it is completely possible to have a "screenlock plugin" that does just that but soon you will need "fullscreening plugin", "vnc plugin", ... A screensaver needs - event spying (to know when the user is active/idle) - also useful to IM clients, input methods (to get the actual events), magnifying glass application (to know cursor position), keyboard launchers (which launch an application whenever a special button is pressed) - event grabbing - to prevent other applications receiving events while the screensaver, and especially the unlock dialog is running - also useful to games and remote desktop clients (to lock input in window), possibly drag and drop implementation (to allow dragging objects over foreign windows), input methods (to get all events while the method is active) - screen grabbing - the ability to paint over whole screen, preventing anything else doing so - also useful to various other applications Some things that a screensaver does not require but other special clients might - event injection - vnc server, input methods (both text input methods and pointer gesture filters) - screen spying - used traditionally by some screensaver effects and useful for magnifying glass application and other effect applications Some things that a "normal" applicationis expected to do but can be still limited in some cases - create arbitrary amount of window(s) of arbitrary size - refresh the window content as often as the application wishes, eg. million times per second - receive events that happen "over" the application window - some windows may not require input and should be marked so so that they don't get focus either - set an receive paste buffers - register paste buffer format convertor These are not that many operations, and given a protocol that includes the concept of security and granting applications arbitrary subsets of these possible access permissions should accomodate pretty much any current application. But the replies so far aside from yours can bu summarized as "Shush, we don't need that, we can just add a hack to the compositor for this". > 1.2 inhibit locking for movie players, slide-shows etc > 1.2.1 what protocol to use to make sure screen saver wont stay inhibited > forever because of broken app > 1.2.2 what communication mechanism to use: compositor/dbus/other > 2. Full screen apps -- need a way to specify that no other windows should be > displayed on top of this one. What if multiple apps want to claim the > screen? > 3 Security issues > 3.1 Protect from bad clients allocating too much pixmap space (and maybe > other resources) > 3.2 Make sure that the password requesting prompts are genuine, i.e. no app > is going to look like another one (screen saver) and request the user pass > in the same way so the user is tricked to enter it inside. I don't think any > other OS tries to do this, but I might be wrong. Other OSes do try, eg NT based Windows. > 4. In case we choose to use apps to implement special features as screen > locking (opposed to compositor[-plugins]) then I don't understand how can an > app authorize itself for the compositor. For example the screen saver app > should tell the compositor that it is that exact app, so the compositor will > grant special privileges (or proxy or arbiter, whatever). So is this process > going to involve asymmetric cryptography, and if yes where is the private > key going to be stored. This may be a very stupid question, but I haven't > seen anything of that sort so I'm wondering how its going to be made. Since on POSIX the unit of security is UID no cryptography is required, a magic cookie like ~/.Xauthority suffices to prove that the application is running under that user on that machine. This should make it possible to run Wayland applications using sudo and not have those applications take over the user's session. The default policy should include some limit on the amount of resources an application can allocate to prevent Wayland going down or being littered by hundreds of windows. It should be possible to raise the limit when needed, and since it is supposed to be something not hit very often it is probably acceptable for this to be implemented interactively - eg. a compositor or a policy monitor opens a dialog box saying "Application 'awdsaf' is trying to open more than 20 windows, do you want to allow it to open another 20?". Of course, there is a possibility that a separate connection will be made for each window and that should be dealt with as well. Since there is no security on POSIX the dialog or associated process manager can provide quite a bit of information about the process(es) opening the offending windows. On systems with real security the magic cookie should be replaced with kernel protected handle which provides a process with the authority to perform some operation(s) on the server that issued the handle. This should also prevent resource exhaustion as the server should not give out handles for more resources than it possesses. Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel