#20775: Use Tor Browser's integrated `AF_LOCAL` support on alpha. ----------------------------------------------+-------------------------- Reporter: yawning | Owner: yawning Type: enhancement | Status: assigned Priority: Medium | Milestone: Component: Applications/Tor Browser Sandbox | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: ----------------------------------------------+--------------------------
Comment (by yawning): Unsandboxed Tor Browser 7.0.1: {{{ socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 67 fcntl(67, F_GETFL) = 0x2 (flags O_RDWR) fcntl(67, F_SETFL, O_RDWR|O_NONBLOCK) = 0 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68 close(68) = 0 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68 fcntl(68, F_GETFL) = 0x2 (flags O_RDWR) fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK) = 0 close(68) = 0 setsockopt(67, SOL_TCP, TCP_NODELAY, [1], 4) = 0 socket(AF_UNIX, SOCK_STREAM, 0) = 68 fcntl(68, F_GETFL) = 0x2 (flags O_RDWR) fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK) = 0 close(67) = 0 connect(68, {sa_family=AF_UNIX, sun_path="/var/run/tor/socks"}, 106) = 0 }}} Without looking into the Firefox source, what I assume is happening in my branch is that the creation of the `AF_INET`/`AF_INET6` sockets fail (with `ENOSYS`) due to the seccomp-bpf rules, and Firefox decides not to actually open the connection that will work. When Tor Browser is configured to use `AF_LOCAL`, the two prior calls shouldn't happen to begin with. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20775#comment:7> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs