[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Merging XenStore+MAC

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


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.