>From: malenovi@plains.NoDak.edu (Nikola Malenovic)
Date: 1994年9月29日 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.