Lsof Binaries

I do not recommend that you use a pre-compiled lsof binary.  It is
better that you compile lsof for yourself from the distributed sources.
But if you can't compile lsof, this set of directory branches contains
some lsof binaries.  They have been compiled on my test hosts, so you
should be careful in using them, since they may not match your
UNIX dialect version or machine architecture.

You can use lsof's ``-v'' option to learn some things about the
identity of the lsof binary: the revision number; when the binary was
constructed; the flags used to compile the binary; and the flags used
to load the binary.

I try to keep these binaries up to date, but the limitations of time,
remembering to do it, and access to some platforms prevent me from
being completely faithful to that goal.

All binaries are compressed, either with bzip2 (.bz2 extension) when it
is generally available on a UNIX dialect, or with gzip (.gz extension).

The path name includes the lsof revision number.  The README files in
the subdirectories explain any further organization.  Please read them.

	TRANSFER LSOF BINARIES USING FTP'S BINARY MODE.

Bunzip2 may be found at http://sources.redhat.com/bzip2/.

Gunzip may be found at ftp.gnu.org in pub/gnu/gzip.


AFS
===

None of the binaries has been compiled for an AFS configuration.


SECURITY MODE
=============

Unless otherwise noted in their README files, these lsof binaries were
compiled with the HASSECURITY definition disabled.  (It's defined in
machine.h in each dialects/ subdirectory.)

When HASSECURITY is disabled, anyone who can run lsof, based on your
installation location and permissions, can list open files for all
processes.

When HASSECURITY is enabled, non-root users of lsof can list files only
for processes they own.  See the 00FAQ and 00README files of the lsof
distribution for a discussion of how HASNOSOCKSECURITY can modify
HASSECURITY's behavior.

Using lsof's -h option will tell you the state of its security mode.


INSTALLATION
============

Lsof requires special permission modes and ownerships to allow it to
access protected resources.  Consult the install rules in the dialect-
specific Makefiles for suggestions.


SECURITY
========

Each bin subdirectory that contains binaries contains MD5 and sum(1)
checksums for the binaries in the file CHECKSUMS.  It also contains a
GPG certificate for each binary file, named <binary_file>, in a related
file, named <binary_file_name>.sig.  The certificates are signed with
my Public GPG Key.  My key may be available from key servers under the
name:

	Victor A. Abell <abe@cc.purdue.edu>

but the key server instance might be an older PGP 2.6.2 key.  (See
below for information on using it with GPG.)

My GPG key is also available at this URL:

	ftp://vic.cc.purdue.edu/pub/Victor_A_Abell.gpg

Once you have added my key to your public key ring, you can check the
signature of a binary file with:

	gpg --verify <binary_file_name>.sig <binary_file_name>

Note: if you have my public key in PGP 2.6.2 format, consult the 00FAQ
file of the lsof distribution for information on adding it to your GPG
keyring.


Cautions
========

Lsof is a tool that is closely tied to the UNIX dialect operating
system version.  It uses header files that describe kernel structures
and reads kernel structures that typically change from OS version to OS
version.

DON'T TRY TO USE AN LSOF BINARY, COMPILED FOR ONE UNIX OS VERSION, ON
ANOTHER.

On some UNIX dialects lsof versions may be even more restricted by
architecture types.

AVOID USING BINARIES FOR LSOF REVISIONS BELOW 4.63.  THEY ARE
VULNERABLE TO THE STANDARD I/O DESCRIPTOR ATTACK.  (See 00FAQ for more
information.)


Vic Abell
February 17, 2004