Unix platforms shouldn't mask errors specific to Unix domain sockets

Jim Blandy <[email protected]> Thu, 15 Aug 2013 17:12:38 -0700
Newsgroups gmane.comp.mozilla.devel.nspr
Message-ID <[email protected]>
... or at least that's the thesis. I'm new to NSPR, so please point me 
in the right direction.

The socket manipulation functions in NSPR use errno-to-PR_FOO_ERROR 
mapping functions that map errno codes for filesystem-related errors 
(EACCESS; ENOENT; etc.) all to PR_ADDRESS_NOT_SUPPORTED. According to 
CVS annotate, this code has been present since revision 1.1 (March 1998).

The rationale for this seems to be that "NSPR doesn't support 
Unix-domain sockets". However, the rest of NSPR seems to support them 
pretty well: PRNetAddr and its associated functions are all prepared for 
PR_AF_LOCAL, and connect, etc. seem to work fine. The only missing 
pieces I'm aware of are the lack of coverage in pr/tests, and this oddly 
preemptive errno code remapping.

(Background: Mozilla's Developer Tools team wants to use Unix domain 
sockets as a more secure way to make debugging connections from 
development machines to Firefox OS devices. Having the main FxOS process 
listen for TCP connections, even only from localhost, is considered too 
risky. However, ADB can forward connections to Unix domain sockets, and 
the kernel applies filesystem permission checks to such connections, 
allowing us to tighten things down a bit more. It would also enable a 
more pleasant chrome debugging user experience, as we could place 
sockets in profile directories; profile names would be a more meaningful 
way to designate debuggees than TCP port numbers.)

I've got patches for Necko, which seem to work pretty well, that add 
Unix domain socket support to the necessary XPCOM components. But when I 
began testing the error handling, I ran into the strange remappings in 
unix_errors.c, and was disappointed.

What would folks say to a patch like the attached?