[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch: Fix user authentication + MKDB
From: |
Dirk Schenkewitz |
Subject: |
Re: Patch: Fix user authentication + MKDB |
Date: |
Wed, 25 Sep 2002 12:25:04 +0200 |
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
- Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/23
- Re: Patch: Fix user authentication + MKDB, Lars Henriksen, 2002/09/25
- Re: Patch: Fix user authentication + MKDB,
Dirk Schenkewitz <=
- RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/25
- RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/26
- RE: Patch: Fix user authentication + MKDB, Yngve Svendsen, 2002/09/27
- Re: Patch: Fix user authentication + MKDB, Lars Henriksen, 2002/09/27
- RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/27
- Re: Patch: Fix user authentication + MKDB, Lars Henriksen, 2002/09/27
- RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/27
- Re: Patch: Fix user authentication + MKDB, Lars Henriksen, 2002/09/29
- RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/29
RE: Patch: Fix user authentication + MKDB, Pankaj K Garg, 2002/09/25