Scott Rotondo wrote:
> 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.
>
>
The distinction between admin_low and admin_high in TX is about what
global zone data is shared with all zones, and what is private to the
global zone. Originally, this included all the sparse-root zone
directories (/usr, /lib, /opt, ...) and anything special like
/var/tsol/doors. /etc/passwd and /etc/shadow. Now that sparse root
zones are unsupported in OpenSolaris, there are only a few files and
directories that are treated as admin_low, not entire datasets. So there
is limited value in labeling a dataset with the admin_low label.
The rationale of this PSARC case is to make labeling more robust by
preventing the administrator from incorrectly mounting ZFS datasets, and
to facilitate determining the label without mounting the dataset. A
mount time, label are validated against the mount point since these two
properties can be set independently. The utility of distinguishing
between admin_low and admin_high labels would be to validate that these
label properties are consistent with the readonly property.
--Glenn
