Kyle McDonald wrote: > 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.
If the systems are networked, who not let the lab proctors login through the network and do the management? >> 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. > We introduced 2 authorizations smf.management.vt smf.value.vt. They are all granted to the Device Security profile. You can use this profile if you do not want give out "root", or just grant the authorizations to some other role. > 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, I think in your case disabling the locking screen feature of virtual console will fit. It would make virtual consoles function a lot like Linux. Or you can grant the smf.management.vt and smf.value.vt authorizations to a role and let that role do the cleaning via network. Does the above solve your problem? I sensed that you naturally do not like root unlock either, because you do not want to give out "root". Your problem is actually RBAC related. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright.
