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.