Re: abstract Unix-domain sockets

On 2020-11-09 07:08, Michael Paquier wrote:
> As abstract namespaces don't have permissions, anyone knowing the name
> of the path, which should be unique, can have an access to the server.
> Do you think that the documentation should warn the user about that?
> This feature is about easing the management part of the socket paths
> while throwing away the security aspect of it.

We could modify the documentation further.  But note that the 
traditional way of putting the socket into /tmp has the same properties, 
so this shouldn't be a huge shock.

> When attempting to start a server that listens to the same port and
> uses the same abstract path, the second server started still shows
> a hint referring to a file that does not exist:
> LOG: could not bind Unix address "@tmp/.s.PGSQL.5432": Address already
> in use
> HINT: Is another postmaster already running on port 5432? If not,
> remove socket file "@tmp/.s.PGSQL.5432" and retry.
> 
> Instead of showing paths with at signs, wouldn't it be better to
> mention it is an abstract socket address?

The @ is the standard way of representing this in the user interface and 
the configuration, so it seems sensible to me that way.

> I am not sure that 0002 is an improvement.  It would be more readable
> to move the part choosing what hint is adapted into a first block that
> selects the hint string rather than have the whole thing in a single
> elog() call.

Can you sketch how you would structure this?  I realize it's not very 
elegant, but I couldn't come up with a better way that didn't involve 
having to duplicate some of the error messages into multiple branches.

-- 
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/