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/
