Re: Design principles and ethics

[Bas Wijnen]

On Mon, May 01, 2006 at 03:33:55AM +0200, Marcus Brinkmann 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?

Indeed, 'su' is not spawned by you.  Well, due to its nature, it must first
parse its commandline before it knows who must spawn it, so in fact it will be
a script which does this and contacts the appropriate user session (in much
the same way the terminal login does that).  This script is spawned by you.

> 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.

Direct, or through some sort of wrappers.  In many cases, terminal reset +
login is much preferable over "su" for this reason.  If you really are just
borrowing the terminal for a moment from some other user, this is also the
conceptually correct thing to do.

Of course that doesn't work so well for things like ssh connections, because
there is no protocol for how to "reset" the terminal.  Perhaps this could be
added, but I think this might be problematic due to the limited control of the
ssh server over the physical terminal that the user uses.

> 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.

I would think that in both cases the implementation must be very careful,
although of course we can expect the system to at least not be malicious.

> 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.

I can't really see how this would be done anyway.  It seems the most logical
to me that the users just do it themselves without the system having anything
to do with it (except giving capabilities so the sessions are able to contact
the others), ...

> 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).

But that may just be because I'm expecting Hurdish solutions. :-)

> > > > 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.

No, it isn't.  The login screen only lists the names of the users, or has some
other means of selecting a user (such as typing the username).  Then the login
agent passes full control over the terminal to that user session, which can do
any type of authentication it wants.  So the the password file is not special
in that it needs external bindings.

> > 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.

It didn't have one in the first place. :-)  Except if you are talking about
the userspace part of the login manager (the authenticator).  In that case,
things are just weird.  But with the default tools we provide, this shouldn't
be possible at all.  So you need to do pretty low-level things if you want to
get in that situation.  If you did, then it's likely that you also know how to
get out (which is, if no other means exist, by destroying the authenticator
and starting a new one with a new password file).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature