Global Resource Coordinator: Basic service internals

services/resource_coordinator/public/interfaces/coordination_unit_provider.mojom

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module resource_coordinator.mojom;
+
+import "coordination_unit.mojom";
+
+interface CoordinationUnitProvider {
+  CreateCoordinationUnit(CoordinationUnit& request, CoordinationUnitID id);

[nasko, 2017/04/21 00:17:32]

I know dcheng@ also commented on this, but what if we start out with an ID
generated in the browser process? If it needs to be calculated (based on origin
and such), then we should evaluate whether we have all the information in the
browser process. If we don't, then we are missing information and we likely
should have it, but if at that point we need the renderer process generating it,
it can be done at the time needed with the exact requirements and limitations
clearly articulated.

[oystein (OOO til 10th of July), 2017/04/21 17:57:55]

I'm slightly confused by this; what's the suggestion exactly? In the current
prototype CL I've got the manifests set up in such a way that only the browser
process can call CreateCoordinationUnit; if a renderer process wants a
messagepipe to a CU, it has to bounce through the browser process. So the in the
cases where we don't want auto-generated IDs, the browser process can either
construct it itself, or validate it at that point.

[nasko, 2017/04/24 22:10:50]

This is where my lack of full understanding of manifests is showing. How is this
actually enforced? Looking at the manifest file, it says coordination_unit is
provided by resource_coordinator::mojom::CoordinationUnitProvider. However, it
doesn't specify any restrictions on which process can call this.

[Ken Rockot(use gerrit already), 2017/04/24 22:17:56]

Services do not specify who is allowed to request their capabilities. That would
necessitate layering violations. Instead they simply name their capabilities so
that any other dependent service in the system may "require" them by name.

The Service Manager enforces the static intersection of provided and required
capabilities. It's up to security review to decide whether one service requiring
any given capability from another should be allowed.

+};