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. [EMAIL PROTECTED] | | / My Wine works. However it crashes about half the time on startup. Apparently their simulation of windoze API is getting too accurate. :) - Kyle Sallee _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs