Closed Bug 971152 Opened 6 years ago Closed 6 years ago

IPv6 detection on linux depends on availability of /proc/net/if_inet6

Categories

(NSPR :: NSPR, defect, P1)

4.10.3
All
Linux
defect

Tracking

(firefox29 affected, firefox30 affected)

RESOLVED FIXED
4.10.4
Tracking Status
firefox29 --- affected
firefox30 --- affected

People

(Reporter: satmd, Assigned: wtc)

References

Details

(Keywords: regression)

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
Blocks: 936320
Status: UNCONFIRMED → NEW
Component: Networking → NSPR
Ever confirmed: true
Keywords: regression
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.
(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.)
Flags: needinfo?(satmd)
Fixed by reverting the alternative test for IPv6 support on Linux: 
https://hg.mozilla.org/projects/nspr/rev/ad00f36fa460
Status: NEW → RESOLVED
Closed: 6 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.