| cea2d3455eb7c0d9ad1430607cbe98cc09251c1f |
|
25-Jun-2015 |
Erik Kline <ek@google.com> |
Use struct android_net_context when interfacing with bionic
Add a new NetworkController::getNetworkContext() that builds the
contents of a struct net_context out of getNetworkForConnect()
and getNetworkForDns().
Bug: 19470192
Bug: 20733156
Bug: 21832279
Change-Id: I5a69b0413a83d33be28b78c0a99359b109517a8f
/system/netd/server/DnsProxyListener.cpp
|
| fe743018ad6ce7fb61db7f6f2efbe9832e9599dc |
|
13-Nov-2014 |
Elliott Hughes <enh@google.com> |
Don't send structs containing pointers over sockets.
Fixes x86-64 netd.
Change-Id: Iee5ef802ebbf2e000b2593643de4eec46f296c04
/system/netd/server/DnsProxyListener.cpp
|
| 1011b4941d96d9fd90bc7243be387b63ec775936 |
|
25-Jul-2014 |
Sreeram Ramachandran <sreeram@google.com> |
Fix fwmark handling for bypassable VPNs and DNS.
This is a significant change to the way fwmarks are handled for two purposes:
1. Bypassable VPN.
This was introduced in http://ag/510058 and had an issue that if there's a
default network, it would always be used in connect(), so the bypassable VPN
wouldn't get any traffic. This CL fixes that issue by using the bypassable
VPN's NetId in connect(). See the comments in the code for more details.
2. DNS.
The previous DNS code (specifically, getNetworkForUser()) had two problems:
+ Even if a user asks for a NetId they have permission for, we'd always use
the user's VPN if they were subject to one. So, for example, a system IMS
app that brings up the mobile network in the presence of a VPN would still
have its DNS queries sent over the VPN, instead of mobile as desired.
+ Any user could perform DNS over any valid network, even one they didn't
have permissions for, as long as they weren't subject to a VPN. So, for
example, an app could use the DNS servers of a different profile's VPN.
This CL fixes those problems. See getNetworkForDns() for more details.
The two pieces above are inter-related. Previously, we never set the explicit
bit from the DNS code. But we need to do that if the user asks for a network
explicitly, for two reasons:
o So that the DNS query is really restricted to that network and doesn't
fallthrough to the default network.
o So that the heuristic described in ON_CONNECT works in all cases. I.e., if the
DNS proxy's connect() request comes in with the explicit bit NOT set, we know
that the NetId can only be either the default network or a VPN.
This CL is not intended to be robust against race conditions. In general, very
little of the netd code is resilient. A separate effort needs to be undertaken
to carefully audit all the code and logic to guard against things like:
* A VPN being established between calls to getNetworkForDns() and connect().
* State changes between multiple calls to NetworkController from clients such as
FwmarkServer and DnsProxyListener.
* Routing rules / iptables rules being set up in a less-than-ideal order.
* ... etc.
Bug: 15347374
Change-Id: I5baad9168c4f4f3ef4129e07234b4bf24b0d8ba2
/system/netd/server/DnsProxyListener.cpp
|
| e09b20aee85f1dfd8c18c3d8581ac875d939ba70 |
|
06-Jul-2014 |
Sreeram Ramachandran <sreeram@google.com> |
Add full support for UIDs in VPNs.
Major:
+ Implement the functions mentioned in http://go/android-multinetwork-routing
correctly, including handling accept(), connect(), setNetworkForSocket()
and protect() and supporting functions like canUserSelectNetwork().
+ Eliminate the old code path of getting/setting UID ranges through
SecondaryTableController (which is currently unused) and mUidMap.
Minor:
+ Rename some methods/variables for clarity and consistency.
+ Moved some methods in .cpp files to match declaration order in the .h files.
Bug: 15409918
Change-Id: Ic6ce3646c58cf645db0d9a53cbeefdd7ffafff93
/system/netd/server/DnsProxyListener.cpp
|
| f4f6c8de3f091be4b91a5a9d7f14e8882ec6d502 |
|
23-Jun-2014 |
Sreeram Ramachandran <sreeram@google.com> |
Refactor: Encapsulate permissions and interfaces into a Network class.
Currently, there's a lot of logic in NetworkController surrounding events such
as interface addition/removal, network creation/destruction and default network
change, because these events are interwined. For example, adding an interface
means also adding a corresponding default network rule if the interface is being
added to the current default network.
When we introduce VPNs into this mix, things will get hairy real quick for all
this logic in NetworkController.
In this refactor, we introduce an abstract base class Network which supports
adding and removing interfaces. The main concrete implementation of this is
PhysicalNetwork, which allows setting permissions and "default network" state.
Since we've moved network permissions into the above class, and user permissions
into NetworkController, PermissionsController is unused and has been removed.
Also fix a few bugs in RouteController:
+ Use uidEnd correctly.
+ Check for all error cases in inet_pton.
+ Check the return value of android_fork_execvp() correctly.
+ The "return cmd1() && cmd2()" pattern is wrong. Rewrite that code.
Also (non-functional changes):
+ Remove instantiations of RouteController. It has static methods only.
+ Reorder some blocks in CommandListener so that the most frequent commands are
checked first.
+ Remove unused paramError() and clearNetworkPreference().
+ Change all return codes to int (negative errno) wherever applicable.
+ Add WARN_UNUSED_RESULT everywhere.
+ Cleanup some style in RouteController and NetworkController.
+ Use uid_t instead of unsigned for user IDs.
+ Add clearer log messages at the source of failures.
+ Add a check for when fwmark bits are set without corresponding mask bits.
Bug: 15409918
Change-Id: Ibba78b0850160f9f3d17d476f16331a6db0025d1
/system/netd/server/DnsProxyListener.cpp
|
| f4cfad361175a7f9ccf4d41e76a9b289c3c3da22 |
|
21-May-2014 |
Sreeram Ramachandran <sreeram@google.com> |
Move netd_client into netd.
Change-Id: Ie4b6b303225c93f2448a503d6ea9cebb552cbad5
/system/netd/server/DnsProxyListener.cpp
|