Aaron Zang wrote: > Jeremy Harris wrote: >> Aaron Zang wrote: >>> If a person is ever allowed to access the local console, he/she >>> should be trusted to behave properly. >>> Virtual consoles could solve by some degree the situation that a >>> person *accidentally* locked several >>> of the available virtual consoles, the system administrator could >>> login via one of the rest of the available >>> consoles and deal with the mess. But if all the available virtual >>> consoles are locked out, what should be >>> blamed is the management of physical access to the local consoles. >> >> All very reasonable for a server-class system. Totally useless for a >> single-monitor, single keyboard system in a student environment. >> > > While in a student environment, it's almost safe to say nothing > important (business/money related) > service is running on that system, so the system admin could even > hammer the system to get it back. > Except for all the jobs of students logged in from home or the dorms through the network, or the long running grad student jobs, that are also running on the machine. They may not be directly Bussiness/Money related, but if the lab proctors (who aren't usually system admins) have to power cycle ot L1-A the machine to unlock the console, then you're going to end up with a bunch of pissed off students who lose work, and eventually some of those will be upset enough to transfer to another school. > The locked system situation is not first introduced by virtual > console, and it's by the nature of locking > screen on a workstation. But all the other methods of locking the screen allow an administrator to override that lock.
I agree with you about the audit context, and the ability of whoe ever unlocked the screen to act as whoever left themsleves logged in. I think if it were linked to a privlege (role? profile? authorization?) instead of 'root' that garrets suggestion would probably be best. Then the sysadmin could give the lab proctor accounts this ability, and a utility to clean out the processes on the consoles. Of course another alternative would be something like 'screen' where virtually an unlimited number of virtual conosle could continue to be created, leaving the locked ones and the processes running. -Kyle > > -- aaron
