Note that the libraries loaded on Linux and Mac (MIT Kerberos and Heimdal) both have extension mechanisms (e.g.: [1] and [2]) where the library may load and execute code based on local configuration. This would make it infeasible to sandbox the code that's invoking the library.

ChromeOS likely has a better story since the local configuration is known.

[1]: https://web.mit.edu/kerberos/krb5-1.12/doc/plugindev/index.html
[2]: http://web.mit.edu/macdev/KfM/KerberosFramework/Kerberos5/Documentation/ccapi/html/index.html

Thanks for the pointers. From what Tom described before, we don't care about sandboxing on Linux as much. ChromeOS and Mac matter though.

Note that sandboxing doesn't block launch, since this code is currently not sandboxed. So if we can do something trivial to get it to work, i.e. by sending the location of the library to load, then we'd unblock canary launch. Then after that in parallel we can look at how to do this in a way that's compatible with sandbox on Mac/ChromeOS.

If there's an extension mechanism, presumably extensions for the library can do arbitrary things once loaded (Like access files), no?

@Matt yeah I believe this is why Asanka said it would be infeasible to sandbox, on Mac and Linux.

On ChromeOS we have control on what's running, so that's a solvable problem.

On Mac, when someone starts investigating the sandbox there they can survey the extensions that are used and see whether this has to be run out of process.

Or we can load it in the browser process - that's a big change, but when I was thinking I'd tackle auth, it's what I was thinking I'd look at.

@mmenke: since it's a big change and not required for launch, I think we should punt that and focus on launch-blocking feature work.

Yea, if we're going for a non-sandboxed launch, I agree with that.

Some rough thoughts here:
1. Do we need to pass the gssapi library path from the NetworkService constructor?
2. The IOThread constructor uses PrefService to get the gssapi library path name:
https://cs.chromium.org/chromium/src/chrome/browser/io_thread.cc?l=328-330
If we need to do similar thing for NetworkService constructor, we may need a mojom::NetworkContextParams* parameter in the NetworkService constructor, since it is needed to create a JsonPrefStore to get a PrefService, similar to:
https://cs.chromium.org/chromium/src/services/network/network_context.cc?l=394-413

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b

commit 6ff5de8947b3112e1fdf9defc919a5125b9f4d2b
Author: Jun Cai <juncai@chromium.org>
Date: Wed Apr 11 04:30:18 2018

Network Service: Load GSSAPI library with network service

This CL updates NetworkContext::MakeURLRequestContext() to load
GSSAPI library for network service.

Bug:  819241 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I940a33a19eb20a7a8dd279757e0047fcc973a17e
Reviewed-on: https://chromium-review.googlesource.com/985130
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549756}
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/chrome/browser/net/profile_network_context_service.cc
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/network_context.cc
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/network_context.h
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/network_context_unittest.cc
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/network_service.cc
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/network_service.h
[modify] https://crrev.com/6ff5de8947b3112e1fdf9defc919a5125b9f4d2b/services/network/public/mojom/network_service.mojom