[libvirt] [PATCH v1 09/23] lock_protocol: Add two new remote procedures

[Peter Krempa]

On Mon, Oct 12, 2015 at 12:25:54 +0200, Michal Privoznik wrote:
> These procedures will be used to store and bring back security
> labels. So far, the idea is that tuple (path, model, label) is
> enough. Well, certainly for DAC and SELinux. The functions are:

I'm afraid that a 'path' per-se isn't enough to express storage
locations in a unique way. Said that a string is fine though, but I'd
rather call it 'identifier' or something similar and explicitly
document some formats for possibly other storage systems that might use
security labeling but don't have a local representation in the host.

I'd imagine something like:
STORAGE_SYSTEM_UUID:VOLUME_UUID
and perhaps
HOST_UUID:/path for local files

One other thing to consider is that if this approach will be used across
multiple hosts the paths although equal string-wise might not result
being the same file. Not honoring that would result into security
implications.

> 
>   VIR_LOCK_SPACE_PROTOCOL_PROC_REMEMBER_SECLABEL
>   VIR_LOCK_SPACE_PROTOCOL_PROC_RECALL_SECLABEL
> 
> Yeah, they really need that VIR_LOCK_SPACE_PROTOCOL_PROC prefix
> due to way we call gendispatch.pl.
> 
> So the former will take the whole tuple and remember it. The
> latter will then take just pair of (path, model) and return label
> stored previously. Moreover, the return value of recall will be
> important: value greater than zero means @path is still in use,
> don't relabel it. Value of zero means @path is no longer used,
> and a negative value means an error (e.g. @path not found, OOM,
> etc.).

I wanted to suggest other constraints but found out that they are
actually documented in the patch that adds the API for this RPC.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151016/528387a3/attachment-0001.sig>