On 10/12/2015 06:25 AM, 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:
>
> 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.).
>
> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> ---
> src/lock_protocol-structs | 15 +++++++++++++++
> src/locking/lock_daemon_dispatch.c | 21 +++++++++++++++++++++
> src/locking/lock_protocol.x | 29 ++++++++++++++++++++++++++++-
> 3 files changed, 64 insertions(+), 1 deletion(-)
>
Disclaimer: My working knowledge of seclabels is limited. I know what
they are, but never dug into the details. They remind me of an OpenVMS
technology that I knew quite well years ago (known as ACL's)... However,
it seems in general they are passed around as character strings, so
that's my working idea...
As I started thinking about this - essentially you're looking to
generate a object in virtlockd that has a unique name for which you'd
like to store/save of some character string context so that at some
point in time that context could be restored.
Without looking too far ahead, I'm assuming this concept is to handle
the 'dynamic' seclabel type's and the static relabel='yes' types in
order to allow a relabel after libvirt is done. So you're then saving
the "model" (dac, selinux, apparmor) and provided "label" (specific to
the model).
I think Peter covered some issues around the 'path' which could/should
be able to describe the 'identifier' object.
Again, not looking forward and just thinking in terms of what's in a
"<seclabel.../>"... Since it's possible to have multiple seclabels for
each 'path'/'identifier' - I assume you must have built in some logic to
first search on the identifier, then if found using the model in order
to determine if something was already defined for that. If so, you're
returning '1' for already in use; otherwise, you create and return '0'
on success and '-1' on failure. So in a way, the code would seemingly
already have a way to take a unique object name and search to determine
if the 'payload' type already exists and make decisions from there.
Since you've set @generate to none that says to me the virtlockd would
then have some "built-in" knowledge about the format of what is being
received so that it can make decisions about what to return. That got me
to thinking about other uses...
Although the design center is security labels for disks and the naming
is centered around that, it could be a security label for anything,
correct? Or thinking more generically, perhaps a MAC for a network?
Some network filter? A secret for something? Or perhaps a resource (such
as disk) which is currently being used by a pool in which case we don't
want some other pool to use the same resource (yes, I have a bz on that
and IIRC there's a different one dealing with disk usage across domains).
Although with multiple uses of the same "object by name", it seems some
sort of tagging on the payload would be required and a way to handle the
"I don't know this type of 'payload'". I guess what I'm thinking we
should avoid is code copy-n-paste bloat for the "next" remember/recall
item. Although yes, easier to debug and perhaps easier to design if we
don't have to think about other object uses or the future - I would
think we have enough current examples that we could come up with
something generic.
In the end perhaps something along the lines of for remember.
{
*String unique_id; /* char string to uniquely id the object */
int payload; /* Payload type - enum {SECLABEL, ...} */
*String object1; /* Currently "model" - payload specific search */
*String object2; /* Currently "label" - whatever it is to store */
}
John
> diff --git a/src/lock_protocol-structs b/src/lock_protocol-structs
> index 8e8b84f..c45086b 100644
> --- a/src/lock_protocol-structs
> +++ b/src/lock_protocol-structs
> @@ -43,6 +43,19 @@ struct virLockSpaceProtocolReleaseResourceArgs {
> struct virLockSpaceProtocolCreateLockSpaceArgs {
> virLockSpaceProtocolNonNullString path;
> };
> +struct virLockSpaceProtocolRememberSeclabelArgs {
> + virLockSpaceProtocolNonNullString model;
> + virLockSpaceProtocolNonNullString path;
> + virLockSpaceProtocolNonNullString label;
> +};
> +struct virLockSpaceProtocolRecallSeclabelArgs {
> + virLockSpaceProtocolNonNullString model;
> + virLockSpaceProtocolNonNullString path;
> +};
> +struct virLockSpaceProtocolRecallSeclabelRet {
> + virLockSpaceProtocolString label;
> + u_int ret;
> +};
> enum virLockSpaceProtocolProcedure {
> VIR_LOCK_SPACE_PROTOCOL_PROC_REGISTER = 1,
> VIR_LOCK_SPACE_PROTOCOL_PROC_RESTRICT = 2,
> @@ -52,4 +65,6 @@ enum virLockSpaceProtocolProcedure {
> VIR_LOCK_SPACE_PROTOCOL_PROC_ACQUIRE_RESOURCE = 6,
> VIR_LOCK_SPACE_PROTOCOL_PROC_RELEASE_RESOURCE = 7,
> VIR_LOCK_SPACE_PROTOCOL_PROC_CREATE_LOCKSPACE = 8,
> + VIR_LOCK_SPACE_PROTOCOL_PROC_REMEMBER_SECLABEL = 9,
> + VIR_LOCK_SPACE_PROTOCOL_PROC_RECALL_SECLABEL = 10,
> };
> diff --git a/src/locking/lock_daemon_dispatch.c b/src/locking/lock_daemon_dispatch.c
> index 1b479db..2d0bd81 100644
> --- a/src/locking/lock_daemon_dispatch.c
> +++ b/src/locking/lock_daemon_dispatch.c
> @@ -430,3 +430,24 @@ virLockSpaceProtocolDispatchCreateLockSpace(virNetServerPtr server ATTRIBUTE_UNU
> virMutexUnlock(&priv->lock);
> return rv;
> }
> +
> +static int
> +virLockSpaceProtocolDispatchRememberSeclabel(virNetServerPtr server ATTRIBUTE_UNUSED,
> + virNetServerClientPtr client ATTRIBUTE_UNUSED,
> + virNetMessagePtr msg ATTRIBUTE_UNUSED,
> + virNetMessageErrorPtr rerr ATTRIBUTE_UNUSED,
> + virLockSpaceProtocolRememberSeclabelArgs *args ATTRIBUTE_UNUSED)
> +{
> + return 0;
> +}
> +
> +static int
> +virLockSpaceProtocolDispatchRecallSeclabel(virNetServerPtr server ATTRIBUTE_UNUSED,
> + virNetServerClientPtr client ATTRIBUTE_UNUSED,
> + virNetMessagePtr msg ATTRIBUTE_UNUSED,
> + virNetMessageErrorPtr rerr ATTRIBUTE_UNUSED,
> + virLockSpaceProtocolRecallSeclabelArgs *args ATTRIBUTE_UNUSED,
> + virLockSpaceProtocolRecallSeclabelRet *ret ATTRIBUTE_UNUSED)
> +{
> + return 0;
> +}
> diff --git a/src/locking/lock_protocol.x b/src/locking/lock_protocol.x
> index a77a784..bac4f0c 100644
> --- a/src/locking/lock_protocol.x
> +++ b/src/locking/lock_protocol.x
> @@ -71,6 +71,21 @@ struct virLockSpaceProtocolCreateLockSpaceArgs {
> virLockSpaceProtocolNonNullString path;
> };
>
> +struct virLockSpaceProtocolRememberSeclabelArgs {
> + virLockSpaceProtocolNonNullString model;
> + virLockSpaceProtocolNonNullString path;
> + virLockSpaceProtocolNonNullString label;
> +};
> +
> +struct virLockSpaceProtocolRecallSeclabelArgs {
> + virLockSpaceProtocolNonNullString model;
> + virLockSpaceProtocolNonNullString path;
> +};
> +
> +struct virLockSpaceProtocolRecallSeclabelRet {
> + virLockSpaceProtocolString label;
> + unsigned int ret;
> +};
>
> /* Define the program number, protocol version and procedure numbers here. */
> const VIR_LOCK_SPACE_PROTOCOL_PROGRAM = 0xEA7BEEF;
> @@ -149,5 +164,17 @@ enum virLockSpaceProtocolProcedure {
> * @generate: none
> * @acl: none
> */
> - VIR_LOCK_SPACE_PROTOCOL_PROC_CREATE_LOCKSPACE = 8
> + VIR_LOCK_SPACE_PROTOCOL_PROC_CREATE_LOCKSPACE = 8,
> +
> + /**
> + * @generate: none
> + * @acl: none
> + */
> + VIR_LOCK_SPACE_PROTOCOL_PROC_REMEMBER_SECLABEL = 9,
> +
> + /**
> + * @generate: none
> + * @acl: none
> + */
> + VIR_LOCK_SPACE_PROTOCOL_PROC_RECALL_SECLABEL = 10
> };
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list