Re: User sessions, system request

Hi,

On Fri, Jan 18, 2008 at 05:39:12PM +0100, Bas Wijnen wrote:

> It's been a while since anything happened here.  I haven't had any
> comments about my kernel, which I found disappointing (I talked a bit
> about it with Marcus, so I didn't expect new comments from him, but I
> had expected some from others like Jonathan).

I was pretty amazed by what you had done there... And I really didn't
know what to say. Look at it in a positive light: It was so convincing
that there was nothing left to add or to dissent from... ;-)

> There must be a dedicated piece of hardware to do a "system request".
> This should get the user to a menu with some system options.  The
> program must not be able to detect that the user does this (unless the
> user specifically allows it to, which may in some cases be done for
> performance reasons).  This menu has options like "kill program" and
> "add permission to access [resource]".  Some of these options may also
> be accessible from within programs, but they must be reliably
> available for the user in a way that programs cannot fake.
> 
> And in a way the program cannot detect.  For example, the alt-SysRq
> was pretty much designed for this purpose.  However, it is unusable:
> if we find out that a program is malicious, and we want to stop it
> immediately, pressing alt-SysRq means first pressing alt, which the
> program can see.  In response, it can do its worst (thinking it's
> about to die anyway).  This must be avoided.

To be honest, the bit about Alt sounds a bit too paranoid to me...

> First I thought about having user's sessions directly on top of this
> session manager, thus creating a "flat" system, as it is on any OS I
> know.  This sounds reasonable, but it means new users can only be
> added by the system administrator.  And that's something I don't want:
> if I work on something with a friend, and I want him to continue to
> work on it even when I'm not there, then I want him to have an
> account.  If I already have one, I could "fake" this by giving away my
> keys (password, or whatever shape they have).  But this is highly
> undesirable.  So since I obviously should have the right to allow
> this, the system should make it possible for me to do it without
> throwing away my session's security. In other words, I need to be able
> to make a new user account, with all or part of the rights that my own
> user account has.

This is interesting. I already thought about some kind of nested users,
but only as a way to overcome UNIX limitations -- allowing a user to run
programs with subidentities with minimal authority.

I never thought about the possibility of a user creating another "true"
user account for someone else. But it sounds useful, and natural in a
properly designed system :-)

> But if any user can make new user's accounts, then the session manager
> really becomes simply a user itself, which has done this several
> times. It allows its users to receive the break commands, but it gets
> the shift-break commands itself, and goes to the user selection menu
> when it does.  In this menu are only the "top-level" users, but that's
> fine: after selecting which user you want, that user's session
> provides you the login screen in the way it prefers.  If that is
> "enter your password or select which sub-user you want to log in as",
> my friend can also log in. :-)

Another advantage of the user-provided login screen :-)

(BTW, do you remember who originally came up with this idea? I think it
was Marcus who mentioned it in passing and immediately discarded it
again; and you and me who dwelt on it... But I'm not sure anymore.)

-antrik-