Skip to content

Instantly share code, notes, and snippets.

@trisk
Last active November 20, 2015 17:00
Show Gist options
  • Save trisk/fc0df85085aff579cf80 to your computer and use it in GitHub Desktop.
Save trisk/fc0df85085aff579cf80 to your computer and use it in GitHub Desktop.
Dataset namespace identifiers

ZFS namespace delegated (zoned/jailed) datasets

Starting observations

  • Namespaces are ephemeral by nature, only the initial namespace has a predictable ID.
  • Containers are logically persistent if they require persistent data.
  • ZFS datasets are persistent, and it's necessary to preserve the relationship between a container and a dataset.
  • ZFS properties with inheritance makes natural sense for child datasets that are delegated to a container, and for moving datasets to other containers.

Per-container identity mechanisms

We need some kind of identity that can be restored when creating namespaces corresponding to a persistent container. We have two reasonable options for keeping track of identifiers:

  • uts namespace
  • dataset namespace extensions

uts provides a hostname string. As with a normal hostname, value can be changed at any time so there is no way to prevent collisions. dataset namespace could gain a zoneid_t/jailid equivalent resource that is unique across physical host.

With the latter approach, we can control access to the identifier and prevent it from being altered within the namespace.

Implemented as id attribute of dataset namespace.

Identifier details

  • UUID probably preferable over 64-bit zoneid_t/jailid since most container frameworks use UUIDs. Parse string form to 128-bit value?
  • Arbitrary string is also an option (and would avoid endianness ambiguity for UUID parsing).

Implementation uses 128-bit value, userspace manages uuid parsing Corresponding property for ZFS datasets

Managing identifiers

clone should clear existing identifier or assign random one; no mechanism available to set non-inherited namespace attributes before creation.

New interface needed to set identifier for newly created namespace clone.

  • Namespace immediately gains access to all ZFS datasets delegated to this identifier.
  • Write access limited to initial namespace (global zone), to avoid spoofing.
  • Needs fd of child namespace for the former.
  • Must scan existing namespaces to avoid collisions.

int datasetns_setid(int fd, <uuid type> uuid)? int datasetns_getid(int fd)?

Still need userspace interface to set id attribute value of namespace, working on new read/write support for procfs node

Implications of delegation

Delegation allows full zfs(1M) access to dataset and children that inherit the property, including zfs mount.

  • Altering identifier on child should force unmount? Or not allow changes to property for mounted dataset?
  • Identifier allowed to be altered from within namespace (to "give away" datasets a la chown on some systems)?

For nesting we'd also need to be able to set the child's container ID from the parent namespace, and not just the initial one.

  • Process tree as authorisation mechanism may not be a good idea?
  • Shared mount namespace would allow one container to manage ZFS on behalf of another, which is cool and not possible with less granular containers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment