Re: [HACKERS] flock patch breaks things here - Mailing list pgsql-hackers

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

I think we need to keep stuff in /tmp.  No reason to add more
configuration just for the sake of it.

If Tom says we can use symbolic links to sockets, why not just do that
for backward compatability.

On my system, all of /tmp is wiped out on reboot because it is a memory
file system.

Let each postmaster start up and create it's own directory as
/tmp/.pgsql.5432 or whatever port number they use.  In the directory, it
can put its socket and pid file.  We also put a pid file in the
postmaster's data directory, and give admins errors if they try anything
funny.

I don't think we can use a main /tmp/.pgsql directory because one system
can have multiple postmasters run by different users.  If we start
putting it in /usr/local/pgsql, we need the socket in a common place,
because the actual pgsql directory can be anywhere, so we need /tmp
anyway.  We can't have clients being configured for different pgsql
locations.

We still have a denial of service attach if someone creates a
.pgsql.5432 directory before we do, but the unix domain socket has to be
in a common place, and we can't just kick people out common territory
because we are not root.

Again, we could put it all in pgsql, but we still need that unix domain
socket, and that can't be configured into the client easily, so I think
we just have to live with /tmp.

Even if we put all the sockets in /tmp/.pgsql, we have the problem of
someone creating /tmp/.pgsql before we start, or after a reboot.  No way
around it that I can see.

In fact, I can't really see a reason for the separate directory in /tmp
vs. what we do now, except that we assume /tmp has the sticky bit, while
creation of our own directory with our own permissions fixes that, which
may be a win, especially because X and others do it that way.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)