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