Ric Aleshire wrote:
> Scott Rotondo wrote:
>>
>>>
>>> When mounting into the global zone proper, the mount will fail
>>> if the dataset has any label other than the default ("none") or
>>> admin_high/admin_low. No automatic property setting is
>>> performed for any mounts into the global zone.
>>
>> It sounds like there are 3 different values for this property that
>> have exactly the same effect. Is there any difference in semantics
>> among these?
>>
>> - slabel=none (or attribute not present)
>> - slabel=admin_low
>> - slabel=admin_high
>>
>> If there is no difference, I suggest that there is no reason to store
>> the latter two. The zfs set command could accept those values and
>> convert them to none, if desired.
>>
>> Scott
>
> The latter two will prevent the dataset from being mounted in any
> labeled zone.
>
> Currently there would be no behavioral distinction between admin_low
> and admin_high
> zfs labels. However, after zfs labels are established by this case,
> the implementation
> of the getlabel interfaces, introduced by 2005/723, will be modified
> to take advantage
> of the zfs property. I anticipate that will result in the ability to
> loopback-mount
> admin_low datasets into labeled zones, which would be appropriate.
The admin_low label implies that the dataset is read-only to all zones,
including the global zone. I think it would be cleaner to use the
existing "readonly=on | off" property instead of having two properties
that both imply read-only semantics. The getlabel interface should
interpret a read-only zfs mount in the global zone to be admin_low,
regarless of the current zone status. However, we still need a value
other than "none" to prevent mounting global zone datasets into a
non-global zones. So the admin_high value seems to meet that requirement.
--Glenn
