Hi -
On Wed, Jun 05, 2013 at 04:32:20PM -0400, Dave Brolley wrote:
> [...] Indeed, experimentation shows that failing to call
> remove/unlink on the object results in EADDRINUSE the next time pmcd
> tries to bind to this address.
Correct, canonical unix-domain-socket code examples do unlink(2)
*before* the bind(2) for this reason. (They can also do an unlink at
program shutdown, just for filesystem cleanliness.)
> The problem is one of euid and file system permissions when running as a
> daemon, as installed. /var/run/pcp is 'drwxr-xr-x. 2 root root' [...]
Ah indeed.
> I have 2 solutions and would like some help in choosing or perhaps there
> is another solution:
>
> 1) unlink/remove the object immediately after binding while we are still
> root.
(Note that it's not just the unlink that should require such privilege
but also the initial bind.)
> In this case, according to remove(3) (which calls unlink(3) in
> this case) and Unix(7), the object's name is removed from the directory
> listing, but the object continues to exist and the socket remains
> available until it is closed. [...]
Does this mean that *new* clients can connect to the unix-domain
socket even after it's unlinked? That'd be very strange, and would
seem to make it unnecessary to have all these unix-domain sockets sit
around in a filesystem for longer than a split second.
> 2) Rework the permissions of /var/run/pcp so that they are 'drwxrwxr-x.
> 2 root pcp'. In this case, the object is visible in /var/run/pcp and can
> be successfully removed at shutdown time.
This is plausible to me.
- FChE
|