> David Holland sez:
 > /*
 >  *  > One of the advantages of BSD Auth is that a non-setuid program can
 >  *  > do authentication checks that require setuid, because the
 >  *  > authentication program can be setuid.  I don't think PAM can do
 >  *  > this.  This might be a plus for, e.g., screen savers.
 >  * 
 >  * Screen savers shouldn't be doing authentication checks. Remember
 >  * lock(1)? It would ask you for a passphrase before locking. xlock 
 >  * should be exactly the same way.
 > 
 > "No. it shouldn't."
 > 
 > 1)  xlock allows you to provide a crypted password for use at lock time.

It seems to me that it ought to offer to crypt it for you also, but
that ought to be trivial to fix if it doesn't.

 > 2)  You should be able to unlock a screensaver with the root password!
 > 	(Otherwise a screensaver could be considered DoS.)   

Why? Just log in from elsewhere and kill -9. lock(1) never behaved
this way, and AFAIK nobody ever cared much.

Furthermore this is an extremely dangerous habit - trivial for me to
run a patched xlock and wander off; then when you come in to unlock
the workstation I rudely left behind, it mails me the root password.

 >      Or you should
 > 	be allowed to use your own password without having to type it in
 > 	(that's antiquated, you've got to admit).

Why should my login password have anything to do with unlocking my
screen? This strikes me as a bad idea in general. 

What about passwordless accounts where you get access via .shosts or
ssh keys or weird site-specific systems? Even if you use PAM, some of
these just plain won't work with xlock. Of course, this in itself
doesn't mean that people who have login passwords and want to use them
shouldn't, necessarily, but I really don't see that typing an 8-letter
word is a big strain.

Ok, so I don't have a good argument against it, but I don't think
"xlock should be able to look up my password" is a good argument to
use when discussing authentication system designs.

 > It seems to this country wolf that something by which password
 > authentication can be done securely without compromising the
 > integrity of the rest of the system would be better than what we've
 > got now.

Yeah, except better yet would be not using password authentication at
all when it's not needed. If you're going to modify the programs
anyway, one might as well do it right.

 > --
 > System V was a mistake.

8-)

-- 
   - David A. Holland             | (please continue to send non-list mail to
     dholland@cs.utoronto.ca      | dholland@hcs.harvard.edu. yes, I moved.)