Aaron Zang wrote:
> 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.
That is still wrong - they are all still built with the feature present.
In current Nevada builds the feature is not enabled by default, but
can be turned on at runtime, without a recompile, by just setting
the flag/properties mentioned.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
