Subject: Re: Files-that-are-commands.
To: Paul Sander <paul@wakawaka.com>
From: D'Arcy J.M. Cain <darcy@druid.net>
List: netbsd-help
Date: 01/12/2000 08:59:04
Thus spake Paul Sander
> Have you considered writing a daemon that writes to a named pipe?
> Use mknod to create a fifo file, and run a program that writes to
> the pipe, then closes it, then writes to it again.  When a second
> program opens the pipe for reading, it will read the initial content
> from the daemon, then get an EOF when the daemon closes the pipe.
> 
> The two programs run in different processes, so setid issues don't
> come into play.  You might put some thought into the permissions on
> the pipe, though.

This is exactly what I did many years ago.  I had a program that read a
configuration file to get the file name to create, the permissions and
ownership for the file, the program to run when opened and who to run
the program as.  It would fork a process for each entry which would
create the named pipe set all the perms, etc then open the pipe for
writing.  This would block until someone opened it for reading.  At
that point it would do the following.

  1 remove the node
  2 fork a new child to start the process again
  3 run the command and feed it's output to the pipe
  4 exit

Note that 1 & 2 almost guarantee that each open for reading gets a new
process.  I say almost because there is an extremely tiny window where
two processes get the same invocation and fight over the output and a
further tiny period where no file exists.  These are pretty small windows
though.

Sorry, I can't find that code (it was on an old SVR4 system) but it is
pretty simple to duplicate.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.