file-system session: root dir as last label element

[nfeske]

Genode's file-system connections accept an optional client-provided root argument (taking / as default), denoting a client-preferred sub directory to be used as root of the file-system session of the client. At the server side, the client-provided root argument is then prepended with the server-side policy for this client. So the client can merely address directories reachable within the restrictions dictated by the server-side policy.

This approach allows an intermediate component to redirect the root of a file-system client by merely changing the client-provided root session argument. The chroot component works this way to great effect (looking at recall_fs). However, when systems become more and more sophisticated, the use of chroot instances for the mere purpose of expressing policy become wasteful. Advanced Sculpt OS users may deploy tens of chroot instances, which becomes a nuisance. With the planned ability to easily assign individual directories in the component-routing dialog, the problem will become even more amplified. Hence, I desire to express the file-system root policy as part of the regular session-label mechanism of init, similar to how label rewriting works today.

Given this motivation, I intend to pass the root-dir argument as last part of the file-system session label instead of a distinct session argument, analogously to how the last part of a ROM-session label is interpreted as a ROM-module name by ROM servers. So each file-system session will have an absolute path as last part of the session label. E.g., the following configuration

  <start name="menu_view" caps="200">
    ...
    <config>
      <vfs>
        ...
        <dir name="fonts"> <fs label="fonts"/> </dir>
      </vfs>
      ...
    </config>
    <route>
      ...
      <service name="File_system" label="fonts"> <child name="fonts_fs"/> </service>
      ...
    </route>
  </start>

will become

  <start name="menu_view" caps="200">
    ...
    <config>
      <vfs>
        ...
        <dir name="fonts"> <fs label="fonts -> /"/> </dir>
      </vfs>
      ...
    </config>
    <route>
      ...
      <service name="File_system" label="fonts -> /"> <child name="fonts_fs"/> </service>
      ...
    </route>
  </start>

In cases where the client's directory structure corresponds to the server's structure, it might be sensible to only use the path as label. If the server in the example above had a /fonts/ directory, the client's <fs> node could be <fs label="/fonts/"/>, which is directly applicable at the server side. In the most common case, where no label is provided, the client's label will be /.

At the server side, policy nodes that refer to specific labels must be turned into <policy label_prefix="..."\> rules because the last part of the session label is no longer only tied to the client's identity but also on the client's root-dir argument. Alternatively, when assuming the client's default of specifying / as label, such policies can be written as <policy label="... -> /"/>.

Once this change is in effect, init can offer a new label-rewriting attribute that prepends the last label element, e.g., turning the client-provided "/bin/" into "/usr/local/bin/" by setting label_prepend_last="/usr/local". To make the 'chrooting" more convenient, we may introduce the attribute dir as an alias for label_prepend_last.

[nfeske]

While adapting Sculpt OS to this change, I encountered the following limitation of my suggested approach.

When routing a file-system session originating from a runtime subsystem towards the Sculpt base system (think of the config fs session of the system shell), the routing rule looks as follows:

<service name="File_system" label="config"> <parent label="config"/>  </service>

The client-originating label is rewritten to "config" so that the static part of sculpt (the parent) can route the session to the config fs according to the well-known label "config". To retain the current semantics, I could simply change to rewritten label to label="config -> /". However, in principle, the client might have supplied a path other than / such as /keyboard/ to only access the sub directory of keyboard layouts. In this case, the rewriting would discard the client's intention and hand out the entire config fs. This is arguably not a risk from security perspective (as we assigned the entirety of the config fs to the component) but it violates the expectation of the client. In the original version, this is not a problem because the client's intent is passed to the server via a plain session argument.

Consequently, we need a way to rewrite labels in a more flexible way, specifically:

• Replacing the identity part of the label (the text coming before the last -> separator) to assign an abstract role (like "ro" or "rw" or "config -> ro") to a concrete client, hiding the client's actual identity from the server.
• Replacing the resource part of the label (the text coming after the last -> separator) to address a server side resource (like ROM module, fs directory) while keeping the client's identity in tact.
• Prepending the resource part of the label to express the "chrooting" of file-system sessions.

Hence, the addition of the label_prepend_last attribute as I suggested above doesn't cut it. Instead, it should better be possible to rewrite the identity and resource parts of the label individually:

• identity="rw" replaces the identity part of the label by "rw" while keeping the resource part.
• resource="/bin/" replaces the resource part of the label by "/bin/" while keeping the identity.
• prepend_resource="/usr/local" subjects the client-provided path to the bounds of the server's /usr/local/ directory.
  Of course, combinations should be possible as well.

Granted, this change introduces additional terminology ("identity" and "resource") instead of speaking of just plain labels. I think, however, that this is defensible as the terms presents the different aspects of the label in a clearer form than today.