Gary Winiger wrote: >>> Well, they are static, no? >> Static to a given site. The issue is that the labels themselves are >> classified information for some customers - usually only the compartment >> bits - and as such it would be better if we could encrypt them so that >> the handling of disks that contain labels could be reduced. > > 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. > 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. -- Darren J Moffat
