On Tue, 2005-10-25 at 22:48 +0200, Bas Wijnen wrote: > On Tue, Oct 25, 2005 at 02:16:35PM -0400, Jonathan S. Shapiro wrote: > > In particular, we probably do NOT want any application to be able to lock a > > terminal up, because then we cannot kill that application. It's not even a > > security issue, really. It's a usability issue. > > If preventing a potential lockup costs that we cannot do useful things, then I > think that cost is too high.
What sort of useful things do you imagine that you are losing? > > Sometimes the right thing is not to ask. In this case, there is no > > conceivable circumstance where the correct thing is for the user to say > > "yes". Under these circumstances, good design practice says that the choice > > should not be offered. > > If only bad things can come from it, I agree. But I see very acceptable uses > from grabbing the display (such as preventing to accidentally typing your > password in the wrong window). No no. This is not "grab", this is "focus". There is a big difference. When you grab the display, you are saying "all input events go to me, including mouse events". When you set keyboard focus, you say "all *keyboard* events go to me". The difference is that the user is still able to switch to another application. It is the ability to switch that I want to protect. Actually, if there is a key sequence like "ALT-TAB" for switching, that should remain available as well. > > Remember that in a persistent system, if you lose control of the terminal > > session you have to delete the user's account to recover! > > Wow, this sounds like the window system is tied way too much to the core of > the system. If this is true, then it isn't possible to log in over the > network and kill a process from there? Or, in this case more likely, attach > not to your whole session but only to a terminal window (perhaps newly > created) from which you can kill it? I can't imagine persistance makes a > system so fragile. It isn't fragile. We've never had to do this. Part of the reason is that we don't let the session be grabbed in a way that the user can't break out of. The persistent model is that when you log in you are *reattached* to your existing session. The session never exits, so logging out does not cause it to become unstuck. On the other hand, your applications don't exit either. I haven't thought about a design that would let you cross-manage sessions. I can see why it might be desirable; we have just never needed it. > If the user explicitly wants this to happen, I think it should be allowed. In > this case, to prevent locked-up sessions, this can also be resolved by > breaking the grab forcefully at login (so after an X reset and reattachment to > the session). It doesn't really matter though: It is only used by developers, > and if it goes wrong, they will know what to do. Bas: grab is one of the reasons why the X window system really CANNOT be the native window system in a secure environment. Another is the lousy design of cut&paste. X11 was explicitly *designed* to be insecure. We can supply sufficient X11 compatibility to applications, but no secure system will *ever* run the X server as its native display server. Anyway: I haven't heard you articulate a use-case that requires grab. So far, what I have heard is "I want it because I'm sure I want it and I'm entitled to it because I'm the user and I'm in charge and I want it." Can you give a clear statement of a real-world use case? Perhaps what you really want isn't a problem even if grab is prohibited. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
