Re: Patch: Fix user authentication + MKDB

[Dirk Schenkewitz]

Lars Henriksen wrote:
> 
> On Mon, Sep 23, 2002 at 05:49:21PM -0700, Pankaj K Garg wrote:
> ...
> >  3) PASSWORD CHECKING: The password checking in the current CVS
> >    directory is broken. It was not working as someone else also
> >    recenlty noted on this list. The problems were: (a) it was using
> >    the opposite logic of match(), (b) it did not default to plain
> >    text passwords, (c) an empty database list was confusing it, and
> >    (d) there was no fall-through.
> 
> I agree with (a) and (c), but not with (b); (d) should be considered.
> 
> As for (b), the password checking behaves as described in version 4 of the
> gnats manual (Keeping Track), see section C.4. Yngve Svendsen put a lot
> of work into this and I believe it behaves as intended. There is no
> "default". You get the kind of password checking you ask for:
> 
>    plain text for passwords with a $0$ prefix,
>    MD5 format for passwords with a $1$ prefix, and
>    DES format for passwords without a prefix.

IMHO this is better than default=plaintext-passwords.

> ...
> Now for (d); I'll assume that gnats is kept as is with no "default"
> password checking. For the discussion I'll change your example to read
> 
>         foo:$0$test:edit:
>         *:$0$*:view:
> 
> >    The desired behavior should be that in case a user fails the password
> >    check for 'foo' then he should be allowed to have a 'view' access
> >    as everybody else. The current code will default 'foo' with a bad
> >    password to 'no_access'.
> 
> This is new behavior, but worth consideration. As it is, the user access
> file is processed like the Unix password file: the first line with a
> matching user is used. But with an all-user entry (or several-user entries),
> it makes a lot of sense to continue processing. If adopted the behavior
> should of course be documented in the manual.

I believe, a fall-through/continued-processing would be a good thing.

If you don't want anybody to read your database, you can have a password
even for reading. But what if a user mis-types his password? If there is
another possibility that fits him (without a proper password), he might
be silently put in "anybody else"-status with read-only-access. That can
be unwanted. Then again, if for "everybody" or "a group of users" read-
only-access is desired, why not give them empty passwords ? As in:

         foo:$0$test:edit:
         *::view:

Then the behavior IMHO should be:
 - user foo gives correct password  --> 'edit' access
 - user foo gives wrong password    --> no access
 - user foo gives no/empty password --> 'view' access
 - user bar gives any password      --> no access
 - user bar gives no/empty password --> 'view' access

Would that be possible ?

> What do others think?

:-) well, I'll repeat that :-)

greetings
        dirk
-- 
Dirk Schenkewitz 

InterFace AG                 fon: +49 (0)89 / 610 49 - 126
Leipziger Str. 16            fax: +49 (0)89 / 610 49 - 83
D-82008 Unterhaching         
http://www.interface-ag.de   mailto:address@hidden