Aaron Zang wrote: > Michael Schuster wrote: > > >>> Anyway, I still believe that the trend is to not using rootunlock. I >>> still >>> remember that around Nevada build 30, xscreensaver supported >>> rootunlock by >>> default, and now it is not the default behavior. >>> >> IMO it would make sense to retain the capability, but turn it off by >> default. >> > > There are actually other reasons that we want to get rid of root unlock, > as stated as reason #2 and #3. The Xsession lock is just one aspect. > > A more serious problem that can be resulted from root unlocking is that > root user can unlock a normal user's console and get this normal user's > attribute without any record. Of course, root user can always do this by "su", > but the "su" could be audited if audit is enabled. > Whereas in our case, the right way to do audit is to set up audit context > from the ucred of the process running on the virtual console being unlocked. > If we allow root unlock, and we want to record this behavior, we have to > make up a fake root audit context, and this is really a very bad thing to do > and is not a correct behavior as allowed by audit. > The above may explain "It can also lead to incorrect attribution of actions > to the locking user by another user." as stated in reason #2. > > When Running large computer labs at universities, this root-unlock feature has been a godsend for when users lock their terminals and leave the lab, and there are no other workstations available for new users.
What if the only thing the root password could do was to unlock *and* logout the session on that console. In other words they wouldn't be allowed access to the running processes, they would just be returned to the login prompt. What I never liked was that it meant we needed to give the lab proctors the root password to the lab workstations. Maybe something could be done with with roles, profles, etc. for this? - Kyle > -- aaron > > >
