- 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.
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
namespacedataset
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.
- 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
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
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