Re: [MirageOS-devel] Merging XenStore+MAC

[David Sheets <sheets@xxxxxxxxxxxx>]

On Thu, Sep 11, 2014 at 5:21 PM, James Bielman <jamesjb@xxxxxxxxxx> wrote:
>
> On 09/11/2014 08:41 AM, Thomas Gazagnaire wrote:
>>> Our case is a little unusual in that we want to expose the security label of
>>>
>>>  /local/domain/1/name
>>>
>>> as a virtual path:
>>>
>>>  /label/local/domain/1/name
>> Is a virtual path a kind of symlink? You don't want to persist it for 
>> performance reason?
>>
>> Just trying to understand the use-cases for maybe implementing this natively 
>> in Irmin :-)
>>
>
> Hi Thomas,
>
> If you think of XenStore like a filesystem, it's more like accessing an
> extended attribute of a node rather than a symlink.  In addition to the
> value stored at "/local/domain/1/name" we also need a way to read and
> write its security label.
>
> Using a virtual file system like "/label" lets us do this without
> needing to modify the XenStore protocol.  One could imagine extensions
> to the XenStore protocol to make this more explicit, but we're currently
> using this "/label" solution so protocol changes aren't required.
>
> I do think this data should be persisted---my concern is that persisting
> security labels could raise consistency issues that don't come up when
> everything is in-memory (because nodes might be created while our
> security module is disabled or a different policy is loaded, leading to
> them having missing or inconsistent labels).  I suppose this situation
> is not that different from a policy reload though, so perhaps this is a
> non-issue.  I just need to think about it a bit more.
>
> Personally, I don't think any Irmin changes are necessary---my plan is
> to add either a "label" field or a map of "extended attributes" to
> XenStore's "node" type and it will be stored like all the other data
> associated with the node.  Then I want a translation within XenStore
> that routes "/label/X" to "X.label" rather than the usual "X.value".

Hi James,

I would like to humbly suggest that you name your virtual root
"/label#/" rather than "/label/" for the following reasons:

1. By appending "#", you can now also have a sibling to "/label#/"
called "/label" which, when read, can describe the nature of the
virtual file system.

2. Receivers of a path like "/label#/X" can know that something funny
is going on when they dereference the path by simply looking at the
structure of the path to determine where they can find what
strangeness awaits them.

3. No extra semantics or work needs to be done immediately to enable
these future use cases, simply changing the name of the virtual root
is sufficient.

4. The structure of the descriptive node can contain further
parameters so that the view into the virtual tree is explicit and
configurable. For instance, policy specifics could be included which
would help with later reconciliation.

Thanks for your consideration,

David

> Thanks,
> James
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel