[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System password authentication

From: Eric Siegerman
Subject: Re: System password authentication
Date: Tue, 15 Apr 2003 01:55:19 -0400
User-agent: Mutt/1.2.5i

On Fri, Apr 11, 2003 at 05:47:15PM -0400, Larry Jones wrote:
> Brian Murphy writes:
> >
> > But this code rejects a blank password "" given by the user, should that not
> > be accepted according to your explanation.
> [...]
> you're also correct that it accepts a non-blank entered password as
> matching a blank system password but rejects a blank entered password. 
> I have no idea why -- the code seems to have been that way forever.

The log message for the original version of that code, way back
in 1.43, was:
        * server.c (check_password): If user has a null password, then
        just return 0.
        Reverse sense of return value.  Caller changed.

My guess would be that in doing the two things at once, he got
confused and coded his new test to the old interface, in which 0
meant *success*.  (check_password just returned a boolean value
in those days, not a pointer.)

The comments were written years later, by someone else, and
appear not to make much sense either.  Of course their author
must have assumed the code was doing something reasonable :-)

> The
> fascist side of my personality wants to reject any attempt to use a
> system account with no password, the more liberal side says that if
> someone is stupid enough to have an account with no password then they
> deserve whatever happens


> (one can argue whether than means accepting any
> password at all or just a blank one).

If the "password" field in /etc/passwd (or /etc/wherever-else) is
empty, UNIX login traditionally doesn't even prompt the user for
a password.  Linux Mandrake 7.2 and FreeBSD 4.8 are still like
that, but Solaris 7's login treats the password as expired and
prompts me for a new one.

If, on the other hand, the field contains the encrypted version
of "", the user *is* prompted, but only a null line is acceptable
as a response.  That's still true in Solaris.  I don't know about
the others -- it's harder to test on them, since their passwd(1)
commands refuse to let me set an encrypted-null-string password.

Ideally, CVS would emulate login's behaviour, by not prompting
for a password if the field is null.  But the little I know of
CVS's internals suggests that trick is impossible -- by the time
the username hits the server, I imagine the password's already
been prompted for.

Given that, it seems to me that "least surprise" should trump
emulating login's intent -- CVS should accept only a blank
password, *not* any at all.

> Opinions from the peanut gallery?

Yeah.  Anyone actually doing this is going to find their
repository -- if not their network -- resembling peanut *butter*

The "no-password == no-prompt" trick would have been useful in
CVSROOT/passwd, though, for read-only anon-CVS access -- no less
secure than publishing the password on a web site as everyone
does now, but certainly less annoying.  Oh well.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
My Wine works.  However it crashes about half the time on startup.
Apparently their simulation of windoze API is getting too accurate.  :)
        - Kyle Sallee

reply via email to

[Prev in Thread] Current Thread [Next in Thread]