Noah Misch <> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to