Date: Sun, 17 Aug 1997 12:17:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Password Handling Message-ID: <199708171917.MAA07163@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970816170852.435A-100000@counterintelligence.ml.org> from "Jamil J. Weatherbee" at Aug 16, 97 05:38:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been looking through the source code to login.c and various .h files, > can someone tell me why login.c defines NBUFSIZE (size of the login name > buffer i think) as UT_NAMESIZE+64, where UT_NAMESIZE is 8 (from utmp.h), Read the comment immediately before the definition: "Allow for authentication style and/or kerberos instance" Then read the 20 or so lines of code immediately below the comment... the point is to allow the input of options for kerberos or another authentication style argument, in addition to the user name. > even though MAXLOGNAME from sys/param.h is 12. sys/param.h is a kernel header. Ignore values there unless you are talking to kernel interfaces (published or via libkvm grovelling in /dev/kmem). > The reason I am asking is that I am designing a server that requires > user logins (I have looked at ftpd.c also) and am wondering if it is > appropriate to use the figure in sys/param.h as the max user name length. No. Use the value from utmp.h, it is the value the rest of the system will use. Sidebar: You must be running old code if this value is 8. > Also another thing that confuses me a bit with freebsd is crypt is > systems that use DES you can do a crypt on the plain text and a > strcmp against the encrypted password returned from getpwnam(), in > freebsd with shadowed passwords and either md5 or des are password > checks handled the same assuming your daemon is running uid 0? The actual password field values are accessable only to root. If they were not, then your system would be succeptible to password cracking techniques, including dictionary-based attacks. Your daemon should verify the user credentials, and then give up uid 0 in favor of the uid associated with the credentials. This assumes that the daemon is verifying the credentials against the system user database, and not a service-specific user database... probably the case, or your question would be meaningless (if a daemon is maintaining it's own user database, it can maintain it however it wants, shadow passwords or not, etc.). Things which verify passwords are gatekeepers; you must be able to trust your gatekeepers with the keys to the gate. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708171917.MAA07163>