----- Original Message -----
> On 08/08/2013 10:26 PM, Nathan Scott wrote:
> > Hi Dave,
> >
> > ----- Original Message -----
> >> Because we now use the __pm*() API to manipulate addresses using the
> >> __pmSockAddr type, with a little additional parsing, it should be
> >> relatively easy to support "local:[//][PATH]" and "unix:[//][PATH]" as
> >> host access specifiers in the same way as we support hostnames, inet and
> >> ipv6 addresses. These would also be covered by the '*' wildcard. We
> >> should probably also support some sort of specific wildcarding for these
> >> along the lines of "local:[//]*" and local:[//]partial/path/*". The same
> >> would apply for "unix:".
> > *nod* - all sounds good to me.
> >
> So, I went ahead and implemented support for unix:[//][path][*] and
> local:[//][path][*] as I had suggested above. No problems, it all works
> as expected. However, while testing it occurred to me that allowing the
> (possibly wildcarded) path might be overkill. The pmcd only has one unix
> domain socket open for client connections and so, simply allowing unix:
> and local: might be sufficient. Regardless of the path to the socket in
> the file system, the connections will always be coming from users local
> to the pmcd host.
Yep, good point.
> Can anyone see a potential usage scenario where specifying the path
> might be useful? If not, I can easily rip out the code that allows the
> path, or have the path ignored for now.
I can't think of one.
> One missing bit of information is that local:[//][path][*] is equivalent
> to specifying both unix:[//][path][*] and 'localhost'.
*nod*, OK - that makes sense IMO.
cheers.
--
Nathan
|