Scott, It must be the responsibility of the OS to prevent console users interacting with applications when the desktop is locked. No user process should ever be able to bypass the lock mechanism. The reason why it is unclear if this is a Windows problem or not is because Tiny Personal Firewall most likely operates at the kernel level. To do what it does it has to. It may be that Tiny Personal Firewall creates the dialog from within the kernel (not sure if that is even possible) when prompting the console user, despite the console being locked. If this is what is going on, then it's really not an OS problem. Windows is doing it's job by preventing console access to user applications and the desktop. Kernel-level code can do anything on the system, it's the responsibility of the product developers to design their software carefully. If there are low-level dialog functions in the kernel, it might be a good idea to add some checks to determine if the console is locked (of course malicious kernel-level code could write directly to video memory, so this is a safety net for code that follows the rules). Anyone familiar with the Win kernel care to comment ? Dave Ahmad SecurityFocus www.securityfocus.com On Fri, 1 Mar 2002, Scott Nursten wrote: > Not being au fiat with Windows programming etc., I was wondering if this was > standard practice? Surely if the workstation is locked it's supposed to stop > all I/O? > > Isn't this also an OS related bug? No flames please, it's just a question. > :) > > Regards, > > Scott > --
This archive was generated by hypermail 2b30 : Mon Mar 04 2002 - 23:24:01 PST