Re: Securing "make check" (CVE-2014-0067)

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote:
>> What I was envisioning was that we'd be relying on the permissions of the
>> containing directory to keep out bad guys. Permissions on the socket
>> itself might be sufficient, but what does it save us to assume that?

> My first preference is to use the simplest code that POSIX requires to have
> the behavior we desire. POSIX specifies as implementation-defined whether
> connect() checks filesystem permissions. That's true of both directory search
> permissions and permissions on the socket itself.

Surely you are misinterpreting that. If it worked as you suggest,
connect() would provide a trivial method of bypassing directory
permissions, at least to the extent of being able to probe for the
existence of files within supposedly-unreadable directories. I can
believe that there are implementations that don't examine the permissions
on the socket file itself, but not that there are any that disregard
directory permissions during the file lookup.

> I found no evidence either way concerning the prevalence of systems that
> ignore directory search permissions above sockets.

That's because the question is ridiculous on its face, so nobody ever
bothered to address it. I think the burden is on you to show that there
has ever been any system that read the spec the way you propose.

> I don't care for interposing a directory based solely on the fact that some
> ancient systems needed that. Changing unix_socket_permissions is a one-liner
> in each test driver. Placing the socket in a directory entails setting PGHOST
> in the psql and postmaster environments and cleaning up the directory on exit.

Placing the socket anywhere besides the default location will require
setting PGHOST anyway, so I don't see that this argument holds much water.
The cleanup aspect is likewise not that exciting; pg_regress creates a lot
of stuff it doesn't remove.

regards, tom lane