From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Securing "make check" (CVE-2014-0067) |
Date: | 2014-03-04 01:15:41 |
Message-ID: | 22183.1393895741@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-03-04 01:32:13 | Re: ALTER TABLE lock strength reduction patch is unsafe |
Previous Message | Josh Berkus | 2014-03-04 01:09:19 | Re: jsonb and nested hstore |