Re: Design principles and ethics

[Marcus Brinkmann]

At Sun, 30 Apr 2006 20:20:14 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> > > 2. I'm not sure how something like 'su fred' would be implemented in
> > > this style of system.
> > 
> > You mean as sysadmin without entering a password?  No way, unless the
> > user grants access to the sysadmin without a password (provided there
> > is a mechanism to do so).
> 
> Umm. No. I meant *with* the password. The part I am confused about is
> how 'su', which is spawned by me (therefore my child) gains read access
> to all of those password files (which is equivalent to read access on
> the password database).
> 
> I suspect your answer may be that 'su' is not spawned by me, and that I
> have consistently failed to see this. If this is the answer, could you
> confirm?

Hm, this is an interesting question.

First, authentication can either happen by the system, or done by the
user.  Both solutions are possible, and the decision which one to use
has no further impact on the outcome.  Authentication is a bounded
operation, so there is no hard resource management problem.

You also need a way to advertise the user fred of such a login
attempt, but of course you need that anyway.

However, the critical question is who implements the virtual terminal
that fred uses to attach the session to.  If the user who does the
"su" implements the virtual terminal that is given to fred's session
manager, then fred's session manager makes direct calls to the servers
implemented by the user invoking su.  This potentially requires a more
careful implementation than if a system-implemented terminal is used
(recovery boundary?).  This is not a fatal problem, it is just
something to consider.  Fred can have (by several means) reliable
information on what type of terminal he is looking at (user
implemented or system implemented).

If the virtual terminal is always implemented by the system, it may be
more reliable, but the system has to provide some shared resource,
which is a DoS and resource accounting issue.

The Hurdish way would be for the system to stay out of it and just let
the users figure it out (of course, with the appropriate default code
provided).

> > > 3. What happens when the user accidentally deletes their password file?
> > 
> > The user can not login anymore.  Which is a good reason for not making
> > it a normal file in the first place (among other reasons not to make
> > it a normal file), but to have a dedicated service (which can still
> > run in the user's space).
> 
> It occurs to me that this may not be what will happen.
> 
> The password "file" is a standalone object with two bindings: one in the
> user directory and the other held by the login agent. If the user simply
> unbinds their capability, then the situation is that they can still log
> in but they can no longer change their password -- this is true because
> the login agent has not lost *it's* capability.
> 
> This may still be the right thing, but it is decidedly weird!

Ah, you meant "unlink" when you said "delete".  I was thinking about
"destroy".

Thanks,
Marcus