Bug 4631
Summary: | lsof 4.42 reports incorrect NODE for deleted executable | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | schorr |
Component: | lsof | Assignee: | David Lawrence <dkl> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | schorr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1999-08-23 16:15:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
schorr
1999-08-20 20:11:51 UTC
Does this problem still exist in the latest lsof-4.45 from Raw Hide? I upgraded to 4.45, and the behavior is identical. However, I played around a little, and it is now clear that the problem is related to permissioning issues. When I run lsof as root or as the user who owns the process, the output is correct. If I run it as some other user, however, it shows less information (which is understandable, since some parts of the /proc/<fd> directory are not readable), and it shows an incorrect NODE number for the "mem" mapping associated with the executable (the file that shows up as the "txt" mapping when the user has the proper permissions). This seems wrong since the /proc/<pid>/maps data is world-readable and has the correct inode number in it. Thanks, Andy Put a setuid root on the lsof binary if you wish consistent results. In fact, lsof is supposed to be installed setuid root. Red Hat does not distribute lsof with this setting because of the potential security hole that might be introduced on systems where lsof is not used and/or understood. |