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?