Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site aphasia.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!aphasia!gww From: gww@aphasia.UUCP (George Williams) Newsgroups: net.unix-wizards Subject: Re: Re: Another reason why a few sources should come with binary licenses Message-ID: <309@aphasia.UUCP> Date: Sun, 8-Sep-85 22:00:24 EDT Article-I.D.: aphasia.309 Posted: Sun Sep 8 22:00:24 1985 Date-Received: Wed, 11-Sep-85 08:27:35 EDT References: <1149@brl-tgr.ARPA> <455@ki4pv.UUCP> Organization: Green Hills Software, Pasadena, CA Lines: 30 > ] few progs need to see encrypted passwords in /etc/passwd, /etc/group > ] therefore, have non-readable pw file containing this info. > > Login, passwd, newgrp, and su are the main progs which require this > information. However, in many cases, the password in /etc/passwd may > be used by some program that wants to be sure that the person using > it is really who we think it is. > > Any prog may wish this information. A database maintainer (real or > game) may wish to protect certain functions by requiring a password > which is matched against some /etc/passwd encrypted string. This is > certainly a way offered by the documents to verify a person's identity. I think a better solution is to have a setuid program that returns an exit status of 0/1 to identify the user, the program should guarantee a sleep of a few seconds if the user gets it wrong to protect against dictionary searches. Fork/exec may be slow but this sort of thing doesn't happen that often (in my experience less often than password crackers) but if you really care you could hack a system call into the kernel which could take a file descriptor to read from a string to verify, and maybe a filename to read from. George Williams decvax!frog!aphasia!gww I'm not to be found, I'm fully occupied elsewhere. If you wish to find me I shall be in my study. You can knock, but I shall give you no reply. I wish to be alone with my convictions.