If you do a vlock, then enter an invalid password for the user, then enter
the valid root password, vlock keeps the terminal locked. I think the
problem is that vlock is not suid root. At least the problem seems to go
away if it is set 04755 (though it may be PAM or something else). However,
the issue is that someone with console access can issue a vlock -a.
Normally you could simply log in as root over the network and kill the
vlock process (though it would prevent users from using the console until
they could find an admin, a problem on a public workstation or similiar).
However, on machines without network connections (or that are on modems),
this may not be possible, thus forcing a reboot and wasting precious uptime
(this is important to a lot of *nix users I know :P). I first noticed this
on 6.1, and just checked it on a fresh (>week old) 6.2 install.
This is a natural tradeoff caused by using shadow passwords; negative
privildges are limited.
No, I assure you it is a bug. It worked fine with shadow passwords on NIS on 60
desktops we had installed with RH 6.1, and now it doesn't on a few RH 6.2
installs. Also, I noticed that if you supply the USER's password when it asks
for the ROOT password, it will unlock the terminal. If that's not a bug I don't
know what is.
We have about a dozen of VA Linux desktops with VA's customized RH6.2 on them,
and only one of them exhibits this behavior. In addition, we have a couple of
generic desktops with Stock RH6.2 on it which do not work properly. I'm
thinking that it is the 6.2 UPDATE rpms that broke it, but I have not had the
time to verify.
Our environment has both NIS and shadow passwords, and as I said, the vast
majority of our desktops work fine, but a handfull do not. They are all RH 6.2
installs, and I believe they all have had the update RPMs applied. I have no
guess as to what the actual cause of the problem is, as I haven't had the time
to whip out the source and debug it (unfortunately, I probably won't either).
In addition, xscreensaver does not work on these same machines. I suspect the
bug is in a library that these two applications share, but again, I haven't had
time to look into it.