Glenn Faden wrote:
> 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.
>
I was about to agree with you, that there should be a single "admin"
value whose interpretation depends on the readonly property. That avoids
having two different properties that imply a read-only mount.
But to argue the other side for a moment, any other label remains
unchanged regardless of the readonly attribute. That means you can have
a read-only filesystem of any label *except* admin_high. Should a
filesystem full of admin_high data become admin_low if you set the
readonly property?
If the answer to the above question is yes, then presumably setting or
clearing the readonly property will require priv_downgrade_sl or
priv_upgrade_sl, respectively.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
