lih@cunixd.cc.columbia.edu (Andrew Lih) (06/01/89)
I am presently developing a system here at Columbia University to provide user authentication before letting a user use a Macintosh. This consists of having an INIT that, after having the Mac start up the Finder, places a *modal* dialog box on the screen which prompts for a username and a password. When these two are entered, the information is sent to a UNIX daemon which checks whether the username combo is correct by matching it against /etc/passwd. If the login is valid, then control of the Mac is turned over to the user. (We would also like to automatically mount an AppleShare volume at this time via CAP/AUFS at this time, however this is left for future work) If the login is not valid, then the dialog prompting for username and password is displayed again and the Mac is not allowed to be used until a valid username-password combo is entered. The problem: In our project, on the Mac side we check to see if the user idles for more than a minute (or whatever time length we specify). If he idles for more than a minute, a dialog pops up and counts down from 60 seconds and says, "Idle logout in X seconds". The problem is that our routine does not seem to be picking up the key events, only the mouse events, so even if the person has been typing for a whole minute, it will still pop up the idle logout dialog. This is not good, since there are many times when a person does not touch a mouse for several minutes at a time. Could any of you who have written screen savers or have dealt with detecting idle time give me any hints as to why this is not working correctly? This is the condition for LightSpeed C v2.15 that we use to check: if (mMoved(&auStg->gMouse) || EventAvail(keyDown|keyUp|autokey,&theEvt)) { auStg->aTick=0; return(false); } Notes: auStg->gMouse global mouse position from previous call auStg->aTick aTick=0 if there was activity detected otherwise, contains seconds to countdown before idle logout. It should pick up key events as well, but it does not seem to do this. Any help would be greatly appreciated. Thanks in advance! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= """"""" Andrew "Fuz" Lih Columbia University Center | @ @ | Instructional Computing for Computing Activities < ^ > \ - / lih@cunixc.cc.columbia.edu AJLUS@CUVMB.BITNET --- lih@heathcliff.cs.columbia.edu ...rutgers!columbia!cunixc!lih =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= """"""" Andrew "Fuz" Lih Columbia University Center | @ @ | Instructional Computing for Computing Activities < ^ > \ - / lih@cunixc.cc.columbia.edu AJLUS@CUVMB.BITNET --- lih@heathcliff.cs.columbia.edu ...rutgers!columbia!cunixc!lih =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dwb@sticks.apple.com (David W. Berry) (06/01/89)
In article <1560@cunixc.cc.columbia.edu> lih@cunixd.cc.columbia.edu (Andrew Lih) writes: > >I am presently developing a system here at Columbia University to >provide user authentication before letting a user use a Macintosh. >This consists of having an INIT that, after having the Mac start up >the Finder, places a *modal* dialog box on the screen which prompts >for a username and a password. When these two are entered, the >information is sent to a UNIX daemon which checks whether the username >combo is correct by matching it against /etc/passwd. Of course you're removing the floppy disk so they can't boot from it and then switch launch to the hard disk? And disabling the SCSI port so they can't boot their own hard disk... David Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry (A/UX Toolbox Engineer) dwb@apple.com 973-5168@408.MaBell AppleLink: berry1
tim@hoptoad.uucp (Tim Maroney) (06/02/89)
As dwb has pointed out, this scheme is trivial to defeat using a system floppy disk. A Mac will always boot from a floppy disk before a hard disk if the floppy is seen early enough in the boot cycle. And as dwb also pointed out, another hard disk may be attached (though if the Mac has an internal hard disk, it will always boot from that first). So I don't know that what you're doing is all that valuable. Nonetheless, on to your keystroke problem. You didn't say *where* you are checking for the events being available. I assume it is from a trap patch, but which trap? You may be calling from a place that would generally see key-down events as already dequeued. I would recommend that you patch either PostEvent or GetNextEvent; if you do PostEvent, you can check the event type and change your global flags yourself if it's a key down event. (But be quick about it! PostEvent is called at the interrupt level.) If you patch GetNextEvent (at the start, mind you) your EventAvail approach should work fine. If you use the GetNextEvent low-memory global routine, I'm not sure, but the event may have already been dequeued by the time you get called. There is a way to do what you want securely, but not portably. You don't use an INIT; instead, you use the disk's boot blocks. That way, as soon as the hard disk is mounted, the code will get executed. I can't give you any pointers on how to do this, but I have seen a product which does it. It can still be broken by an expert using a debugger, but it's much better protection. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I am of the opinion that my life belongs to the whole community, and as long as I live it is my privilege to do for it whatever I can." -- Shaw
oster@dewey.soe.berkeley.edu (David Phillip Oster) (06/03/89)
In article <1560@cunixc.cc.columbia.edu> lih@cunixd.cc.columbia.edu (Andrew Lih) writes: > > if (mMoved(&auStg->gMouse) || > EventAvail(keyDown|keyUp|autokey,&theEvt)) { > auStg->aTick=0; > return(false); > } Other people have pointed out the larger flaws in your scheme. Here is your programming error: the EventAvail() line should read: EvantAvail(keyDownMask|keyUpMask|autoKeyMask, &theEvt)) { --- David Phillip Oster --"Unix Version 7 was an improvement not Arpa: oster@dewey.soe.berkeley.edu --only over its predeccessors, but also its Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --successors."