Re: [MirageOS-devel] Merging XenStore+MAC

[James Bielman <jamesjb@xxxxxxxxxx>]

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".

Thanks,
James


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