>From: malenovi@plains.NoDak.edu (Nikola Malenovic)
Date: Thu, 29 Sep 1994 07:28:37 -0400

4.9)  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.