At Sun, 30 Apr 2006 18:13:07 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > So you propose that the system-wide login process should have the > ability to read all of these files, but each user should have the > ability write their own? > > This is clever. How do you propose to address the following issues?
You seemed to have missed a whole thread a couple of weeks ago. This is one way to do it. Another way is to let the user verify their own password. Ie, have no system-wide authentication mechanism at all. Anyway, I'll backtrack and answer the questions with the assumption that there is, in fact, a system-wide authentication mechanism. > 1. There are overwhelmingly compelling reasons to set policies against > stupid passwords. It is a matter of judgement if such policies need to be administrator or system enforced. > This is why cracklib exists -- one bad password > endangers an entire system. If this is true, then it is a defect in the system. The fault is in using passwords. Passwords and humans don't mix well. > This implies that even if the user owns the > password file, we wish to restrict the conditions under which that file > can be written. Indeed, using a purely user-defined authentication > methods are a bad idea because of this. Here is a way to do it in the case where the user provides the password file, and the system reads it: The system checks the conditions for the password that is _entered at the login prompt_, rather than the password in the file. It is then the user's responsibility (with adequate support, of course) to set a password that complies to the conditions. > 2. I'm not sure how something like 'su fred' would be implemented in > this style of system. You mean as sysadmin without entering a password? No way, unless the user grants access to the sysadmin without a password (provided there is a mechanism to do so). > 3. What happens when the user accidentally deletes their password file? The user can not login anymore. Which is a good reason for not making it a normal file in the first place (among other reasons not to make it a normal file), but to have a dedicated service (which can still run in the user's space). Originally I was considering a scheme like this, where the user could advertise some information about itself to the system, basically by providing some read-only memory. However, in the end, I was tentatively convinced to go for completely user-defined authentication mechanisms. This and much else was discussed previously. Although my memory may be blurred and part of it didn't make it to the list. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
