Comment excerpted from response when I asked if this was
ok to repost:
"
I've floated the idea of doing this to my test system provider to
see how he feels about my having root permission to do lsof testing.
His response might sqaush this idea. :-)
"
-- Raul-----Forwarded message from Vic Abell <abe@purdue.edu>-----
Reply-To: "Vic Abell" <abe@purdue.edu> From: "Vic Abell" <abe@purdue.edu> To: "Raul Miller" <rdm@test.legislate.com> Subject: Re: lsof doesn't work without module support? Date: Thu, 18 Dec 1997 15:57:49 -0500
Raul,
You write (ion part): > >... > >The kernel dependent stuff should go *inside* the kernel, then, so >that you can have a consistent binary in user space.
This comment made me wonder about the progress of the Linux /proc file system, so I took another look at in on a Linux 2.1.72 system this afternoon.
To my surprise, /proc *almost* provides enough data for lsof. So far I have found missing only these things:
* The file offset, which lsof gets from the file struct. This ought be provided via /proc/<pid>/fd somehow.
* The socket protocol. If all protocol files in /proc/net had inode entries, this might not be necessary by doing a reverse lookup on inode number. But, while proc/net/{tcp,udp,raw,unix} have inode numbers, /proc/net/ipx doesn't. (I need to support IPX with lsof, because one test system provider uses it.)
* The peer to which a FIFO is connected. Since a stat(2) of a FIFO's /proc fd entry yields an inode number, this may not be necessary.
It seems to me there should be a /proc/fifo file or directory, ala /proc/net/tcp, that describes all open FIFOs.
I suspect there may be other data missing from /proc that lsof currently gets via /dev/kmem, but I don't see what they might be at the moment.
One thing I did find is that the symbolic links in /proc/<pid>fd now point to file names. That's an asset in providing file names, but a debit in that it used to provide device and inode numbers. An extra stat(2) will get those values.
One down-side of using /proc is that lsof would need to be setuid(root) to be able to read info on all processes. Right now lsof only needs permission to read /dev/kmem, typically by being setgid(kmem). I don't like setuid(root) and don't know the root password on the systems where I test lsof -- I'm in the kmem group.
The second down-side is that the use of /proc by lsof would require it to assume some relationships between pieces of /proc that might not be there by design or remain. The inode numbers in some, but not all /proc/net files is a good example.
The whole subject certainly deserves more thought. It might even be worth my spending time to see how far I could get coding a /proc based lsof.
Vic
-----End of forwarded message-----