Re: Design principles and ethics

[Marcus Brinkmann]

At Sun, 30 Apr 2006 18:13:07 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> So you propose that the system-wide login process should have the
> ability to read all of these files, but each user should have the
> ability write their own?
> 
> This is clever. How do you propose to address the following issues?

You seemed to have missed a whole thread a couple of weeks ago.

This is one way to do it.  Another way is to let the user verify their
own password.  Ie, have no system-wide authentication mechanism at all.

Anyway, I'll backtrack and answer the questions with the assumption
that there is, in fact, a system-wide authentication mechanism.
 
> 1. There are overwhelmingly compelling reasons to set policies against
> stupid passwords.

It is a matter of judgement if such policies need to be administrator
or system enforced.

> This is why cracklib exists -- one bad password
> endangers an entire system.

If this is true, then it is a defect in the system.

The fault is in using passwords.  Passwords and humans don't mix well.

> This implies that even if the user owns the
> password file, we wish to restrict the conditions under which that file
> can be written. Indeed, using a purely user-defined authentication
> methods are a bad idea because of this.

Here is a way to do it in the case where the user provides the
password file, and the system reads it:

The system checks the conditions for the password that is _entered at
the login prompt_, rather than the password in the file.

It is then the user's responsibility (with adequate support, of
course) to set a password that complies to the conditions.

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

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

Originally I was considering a scheme like this, where the user could
advertise some information about itself to the system, basically by
providing some read-only memory.  However, in the end, I was
tentatively convinced to go for completely user-defined authentication
mechanisms.

This and much else was discussed previously.  Although my memory may
be blurred and part of it didn't make it to the list.

Thanks,
Marcus