User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140210201015 Steps to reproduce: I'm using a kernel with grsecurity patches. I tried to access an ipv6-only website using firefox. The kernel is using CONFIG_GRKERNSEC_PROC which causes restrictions on /proc for normal users. Namely there's no access to /proc/net/if_inet6 for regular users. Digging through all sorts of possible error sources, I stumpled accross this gem: nspr-4.10.3/nspr/pr/src/pthreads/ptio.c: /* If /proc/net/if_inet6 exists, the Linux kernel supports IPv6. */ Next line does an access() on said file which will fail, IPv6 will be disabled in firefox. Other tools not relying on this check work find, for example dig -t aaaa and wget work fine. The check for /proc/net/if_inet6 is simplistic, yet is not a safe assumption. For an alternative, I suggest using a bind() with AF_INET6, checking its return code. Actual results: Accessing named site make firefox present me the "host not found" error page. Expected results: Access to the site shall be possible given the technical availability.
Replacing return (rv==0); by return 1; on the lines right below the check proves that I'm poking at the right spot
A friend directed me at one solution of the problem: https://github.com/inspircd/inspircd/blob/master/src/configreader.cpp#L442
It must be a regression from bug 936320.
Assignee: nobody → wtc
Status: UNCONFIRMED → NEW
Component: Networking → NSPR
Ever confirmed: true
Product: Core → NSPR
Version: unspecified → 4.10.3
Thank you for the bug report. Jed: what should we do now? The new test for IPv6 support is also disallowed in some environment. Should we just assume Linux supports IPv6 and undefine _PR_INET6_PROBE for Linux?
(In reply to Wan-Teh Chang from comment #4) > Jed: what should we do now? The new test for IPv6 support is also disallowed > in some environment. Should we just assume Linux supports IPv6 and undefine > _PR_INET6_PROBE for Linux? I'm increasingly favor of that. I assume that systems with no IPv6 would just fail to socket(AF_INET6, ...) and fall back to a v4 address if available, so the impact would just be some wasted AAAA queries? I guess if there's a broken middlebox that blackholes AAAA queries and the user was working around it by unloading the ipv6 module that would be a problem; can our resolver deal with that? There is another option: reverting the previous patch and using attachment 8364021 [details] [diff] [review] instead.
status-firefox29: --- → affected
status-firefox30: --- → affected
(Sorry for the spurious needinfo; I was going to ask if the version in comment #0 was the one where this was observed, since it doesn't have the patch with /proc/net/if_inet6, but then I saw that comment #1 answers that.)
Fixed by reverting the alternative test for IPv6 support on Linux: https://hg.mozilla.org/projects/nspr/rev/ad00f36fa460
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Priority: -- → P1
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → 4.10.4
You need to log in before you can comment on or make changes to this bug.