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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list