Re: [HACKERS] flock patch breaks things here

   I just came up with an idea that might help alleviate the /tmp security
   exposure without creating a backwards-compatibility problem.  It works
   like this:

   1. During installation, create a subdirectory of /tmp to hold Postgres'
   socket files and associated pid lockfiles.  This subdirectory should be
   owned by the Postgres superuser and have permissions 755
   (world-readable, writable only by Postgres superuser).  Maybe call it
   /tmp/.pgsql --- the name should start with a dot to keep it out of the
   way.  (Bruce points out that some systems clear /tmp during reboot, so
   it might be that a postmaster will have to be prepared to recreate this
   directory at startup --- anyone know if subdirectories of /tmp are
   zapped too?  My system doesn't do that...)

   ...

   I notice that on my system, the X11 socket files in /tmp/.X11-unix are
   actually symlinks to socket files in /usr/spool/sockets/X11.  I dunno if
   it's worth our trouble to get into putting our sockets under /usr/spool
   or /var/spool or whatever --- seems like another configuration choice to
   mess up.  It'd be nice if the socket directory lived somewhere where the
   parent dirs weren't world-writable, but this would mean one more thing
   that you have to have root permissions for in order to install pgsql.

It seems like we need a directory for locks (= pid files) and one for
sockets (perhaps the same one).  I strongly suggest that the location
for these be configurable.  By default, it might make sense to put
them in ~pgsql/locks and ~pgsql/sockets.  It is easy (i.e., I'll be
glad to do it) to modify configure.in to take options like

         --lock-dir=/var/spool/lock
         --socket-dir=/var/spool/sockets

that set cc defines and have the code respond accordingly.  This way,
those who don't care (or don't have root access) can use the defaults,
whereas those with root access who like to keep locks and sockets in a
common place can do so easily.  Either way, multiple postmasters (all
compiled with the same options of course) can check the appropriate
locks in the well-known places.  Finally, drop the link into /tmp for
the old socket and document that it will be disappearing at some
point, and all is fine.

If someone wants to give me some guidance on what preprocessor
variables should be set in response to the above options (or something
like them), I'll do the configure stuff.

Cheers,
Brook