How do I keep track of people who are fingering me?

How do I keep track of people who are fingering me?

Generally, you can't find out the userid of someone who is
fingering you from a remote machine. You may be able to
find out which machine the remote request is coming from.
One possibility, if your system supports it and assuming
the finger daemon doesn't object, is to make your .plan file a
"named pipe" instead of a plain file. (Use 'mknod' to do this.)

You can then start up a program that will open your .plan file
for writing; the open will block until some other process (namely
fingerd) opens the .plan for reading. Now you can feed whatever you
want through this pipe, which lets you show different .plan
information every time someone fingers you. One program for
doing this is the "planner" package in volume 41 of the
comp.sources.misc archives.

Of course, this may not work at all if your system doesn't
support named pipes or if your local fingerd insists
on having plain .plan files.

Your program can also take the opportunity to look at the output
of "netstat" and spot where an incoming finger connection is
coming from, but this won't get you the remote user.

Getting the remote userid would require that the remote site be
running an identity service such as RFC 931. There are now three
RFC 931 implementations for popular BSD machines, and several
applications (such as the wuarchive ftpd) supporting the server.
For more information join the rfc931-users mailing list,
rfc931-users-request@kramden.acf.nyu.edu.

There are three caveats relating to this answer. The first is
that many NFS systems won't recognize the named pipe correctly.
This means that trying to read the pipe on another machine will
either block until it times out, or see it as a zero-length file,
and never print it.

The second problem is that on many systems, fingerd checks that
the .plan file contains data (and is readable) before trying to
read it. This will cause remote fingers to miss your .plan file
entirely.

The third problem is that a system that supports named pipes
usually has a fixed number of named pipes available on the
system at any given time - check the kernel config file and
FIFOCNT option. If the number of pipes on the system exceeds the
FIFOCNT value, the system blocks new pipes until somebody frees
the resources. The reason for this is that buffers are allocated
in a non-paged memory.


Home FAQ