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. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright.
