Noah Misch <n...@leadboat.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers