|Summary:||Can lock up console, forcing reboot in some cases|
|Product:||[Retired] Red Hat Linux||Reporter:||Jack Lloyd <lloyd>|
|Component:||vlock||Assignee:||Michael K. Johnson <johnsonm>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-04-13 15:39:18 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jack Lloyd 2000-04-13 15:39:18 UTC
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.
Comment 1 Michael K. Johnson 2000-07-31 20:11:44 UTC
This is a natural tradeoff caused by using shadow passwords; negative privildges are limited.
Comment 2 Need Real Name 2000-09-26 20:04:44 UTC
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).
Comment 3 Need Real Name 2000-09-26 20:06:29 UTC
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.