From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040706 Firefox/0.9.1 Description of problem: Lock files created under /var/lock are erroneously removed under certain circumstances. Lock files should be removed by a process trying to acquire the lock, if the locking process is not alive any more. However, the test against the existing process id is broken, resulting in an abnormal behavior. Particularly, the kill() system call is used to determine whether a process id (pid) still exists or not. The problem is that the only check is made against the return value, which is expected to be 0 if kill() succeeds and -1 otherwise. However, a failure of kill() does not necessarily mean that the pid does not exist; it may also mean that the calling uid doesn't have permission to kill() the specified pid. I fixed the bug, and a patch is available at: http://radu.rendec.ines.ro/lockdev-1.0.1-pidexists.patch Please consider checking the patch and including it in the official distribution. I also made a patch against the package spec file, which you might find useful. It's available at: http://radu.rendec.ines.ro/lockdev-specfile-pidexists.patch Should you have any questions or comments regarding this issue, please do not hesitate to contact me. Version-Release number of selected component (if applicable): lockdev-1.0.1-1.3 How reproducible: Always Steps to Reproduce: 1.Lock a device as root 2.Try to lock the same device as unprivileged user Actual Results: The lockfiles created at step 1 are replaced by new lockfiles. The process running as unprivileged user thinks the process running as root is dead, because it can't be killed. Expected Results: The process running as unprivileged user should not have been able to acquire the lock. Additional info:
Created attachment 102008 [details] level 1 patch made against already patched (1.0.1-1.3) source tree Merely tested by me on an i386 architecture. Although I don't think it is architecture-dependant, it probably needs more testing.
this is a good patch. goes across cleaning against all our arches-- code looks sane. thanks.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0405.html