Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

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