Alan Coopersmith wrote: > Gary Winiger wrote: >> The vtdaemon service proposed a "rootunlock" property. When the value of >> "rootunlock" was "true", vtdaemon allowed unlocking text virtual consoles >> using the root user's password instead of the locking user's password. >> >> The project team now considers the "rootunlock" property as unnecessary >> because: >> >> 1) Neither xlock nor xscreensaver have such an unlocking feature. > > I don't understand this claim - xlock, xscreensaver & CDE lockscreen all have > a feature to allow unlocking the screen with the root password instead of the > locking's users password, mostly because our customers demanded it be there. > (Whether it's on or off by default differs by OS rev & program, but they > all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in dtsession(1), > and the allowRoot xscreensaver resource defined in LSARC 2006/446 which > we apparently forgot to document in the man page.) >
Yes, these locks all have code supporting root unlock, and there are macros functioning as switches to turn the feature on and off during compilation. Current Solaris releases always turn off the switches (without compiling this feature in). That what we really mean. And the root unlock feature of these locks was turned on in early Nevada build, but has been turned off nowadays, I think that is a sign of the trend -- no root unlock. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright.
