Re: [HACKERS] flock patch breaks things here

dg(at)informix(dot)com (David Gould) writes:
> If the traffic on bugtraq is any indication, writing in /tmp is a
> security exposure for daemons. Typical attack is:
> ln -s /etc/passwd /tmp/dumbrootprog.tmpfile

A partial answer to this is to unlink /tmp/pidfile before trying to
create/write it. There's still a window for the attack, but it's
mighty tiny. (You do have to check that the unlink either succeeds
or fails with ENOENT --- in particular, an EPERM failure is trouble
for obvious reasons.)

I finally understand where Bruce is coming from on this point: he wants
pid lock files in *both* the data dir (to lock the database) and /tmp
(to lock the Unix-socket port number). This makes sense to me, and I
agree that it'd become a lot safer to run multiple postmasters/databases
that way. The data and the port are independent resources and each one
needs a lock.

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

2. When a postmaster fires up, it checks for/creates a pid lockfile in
the subdirectory, and also creates the socket file in the subdirectory.

3. For backwards compatibility with 1.0 clients, the socket file is also
hard-linked to /tmp/.s.PGSQL.port# (use an unlink() and link()).

This way, there's no security risk of overwriting someone else's file,
since we never create or write on a file in a directory we don't own, we
only try to link an already-existing socket file into /tmp.

I'd suggest that the pid and socket files be given names in /tmp/.pgsql
that don't start with dots --- no need to make them hard to see in that
directory.

We can change libpq to find the socket at /tmp/.pgsql/whatever, and
eventually we could perhaps drop the backwards-compatibility feature
of creating a link in /tmp.

> Also, before sprinkling files all over it is good to try to conform
> to the FHS (File Hierarchy Standard) (see http://www.pathname.com/fhs/)
> which is pretty easy to do and likely to make life easier later.

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.

regards, tom lane