Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 4631 - lsof 4.42 reports incorrect NODE for deleted executable
Summary: lsof 4.42 reports incorrect NODE for deleted executable
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lsof
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-08-20 20:11 UTC by schorr
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-08-23 16:15:12 UTC


Attachments (Terms of Use)

Description schorr 1999-08-20 20:11:51 UTC
I started a daemon process and then used rdist to update
the program that was already running.  Since the running
program is holding open the old version of the binary,
rdist of course installs it with a new inode number.
However, when I use lsof to examine the files held open
by the already running daemon process, it shows the
executable with a NODE value equal to the inode number of
the newly installed version.  This is incorrect.  I imagine
that this is because it may be blindly following the
symbolic link in /proc/<pid>/exe instead of looking at
the contents of /proc/<pid>/maps.

Thanks,
Andy

Comment 1 Jeff Johnson 1999-08-20 21:47:59 UTC
Does this problem still exist in the latest lsof-4.45 from Raw Hide?

Comment 2 schorr 1999-08-23 13:22:59 UTC
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

Comment 3 Jeff Johnson 1999-08-23 16:15:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.