I'd started a prototype of something very similar to this and one of the first things I discovered was the issue of binary labels being all that was available in kernel. So I didn't get very far (plus I had other things to do).
Your userland prototype uses user properties, if we use a new "real" dataset property we get to define the access/change policy. The way I'd expect this to work is like this: If the ZFS pool version is >= SPA_VERSION_MLS_LABELS then create any missing dataset properties for the MLS label and there after enforce mounting only at that label. A change of MLS label requires privilege (maybe all since we don't currently have file_mac_ privs) but we need to be careful of the interaction with zfs delegation too. I believe the label change should only happen on an umounted dataset and only in the global zone. If the ZFS pool version is older then don't enforce and don't create the label properties. The internal/external issue for labels needs some thought, my initial desire was to store the external label and translate for comparisons. snapshots/clones should be configured to inherit the parent MLS label in a similar way to what I'm doing for encrypted datasets. This is subtlety different to what happens by default. For encrypted datasets the encryption property stays with the snapshot/clone and stays the same even on a rename to a different part of the dataset hierarchy. I suspect we might want the same behaviour for an mls label but this needs investigation. As for zfs send/recv I'm not sure what all the issues would be yet but I think the things to consider are: a) setting the label property on recv b) receiving when the senders label property differs from the destination dataset label property (upgrade/downgrade). -- Darren J Moffat
