From: malenovi@plains.NoDak.edu (Nikola Malenovic)
Date: Mon, 23 Nov 1992 16:01:45 -0600
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 whatever you want through this pipe, which lets you show different .plan information every time someone fingers you.
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.