> > That's why the internal format (aka hex label) is what is stored.
> > By official government ruling (at least from us DoD) it is
> > unclassified and may be view by anyone.
>
> Does that then mean we can't allow for 'zfs get slabel' to return the
> label_to_str() version ? I could live with that providing we can
> provide the 'zfs set slabel=public' rather than needing to use the
> internal format to do zfs set.
Fortunately, no. Explicitly the translation would be
label_to_str(str_to_label(zfs get slabel), M_LABEL)
As I tried to say (below) takes into account the restrictions
(that is the caller must dominate the label being translated
or the translation will fail). This has been the case since
SunOS CMW 1.0.
> > Indeed the compartment
> > names are generally classified at the level of their name and
> > must not be visible below that level. label_to_str takes into
> > account these restrictions as well as produces the unclass version
> > of an m_label for storage where it doesn't need protection.
>
> If the US DoD is happy with the internal format being treated as
> unclassified then I'm fine with using a property for this providing the
> issue of delegation is okay with the project team - ie it must follow
> the normal delegation rules for properties - I would like to see
> positive confirmation from the ZFS core team that they are comfortable
> with this given the additional information provided.
OK then ;-) I'll be posting a summary of the issues discussed
and responses shortly so we're all on the same page.
Gary..
