[libvirt] [PATCH 3/6] Use private data struct in SELinux driver

Stefan Berger stefanb at linux.vnet.ibm.com
Sat May 12 12:21:57 UTC 2012


On 05/12/2012 05:56 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/11/2012 10:43 PM, Stefan Berger wrote:
>> On 05/11/2012 06:10 AM, Daniel P. Berrange wrote:
>>> From: Daniel Walsh<dwalsh at redhat.com>
>>>
>>> Currently the SELinux driver stores its state in a set of global
>>> variables. This switches it to use a private data struct instead. This
>>> will enable different instances to have their own data.
>>>
>>> Signed-off-by: Daniel P. Berrange<berrange at redhat.com>  ---
>>> +SELinuxInitialize(virSecurityManagerPtr mgr) {
>> [...]
>>> -    ptr = strchrnul(default_image_context, '\n'); -    if (*ptr == '\n')
>>> { +    ptr = strchrnul(data->file_context, '\n'); +    if (ptr&&   *ptr ==
>>> '\n') { *ptr = '\0'; -        strcpy(default_content_context, ptr+1); -
>>> ptr = strchrnul(default_content_context, '\n'); -        if (*ptr ==
>>> '\n') +        data->content_context = strdup(ptr+1); +        if
>>> (!data->content_context) +            goto error;
>> virReportOOMError ?
>>
>>> @@ -264,13 +277,11 @@ SELinuxGenSecurityLabel(virSecurityManagerPtr mgr
>>> ATTRIBUTE_UNUSED, goto cleanup; }
>>>
>>> -    if (!def->seclabel.norelabel) { -        def->seclabel.imagelabel =
>>> SELinuxGenNewContext(default_image_context, mcs); -        if
>>> (!def->seclabel.imagelabel)  { -
>>> virSecurityReportError(VIR_ERR_INTERNAL_ERROR, -
>>> _("cannot generate selinux context for %s"), mcs); -            goto
>>> cleanup; -        } +    def->seclabel.imagelabel =
>>> SELinuxGenNewContext(data->file_context, mcs); +    if
>>> (!def->seclabel.imagelabel)  { +
>>> virSecurityReportError(VIR_ERR_INTERNAL_ERROR, +
>>> _("cannot generate selinux context for %s"), mcs); +        goto
>>> cleanup; }
>>
>> There was this check if (!def->seclabel.norelabel) that's now gone. Was
>> this removed by accident?
>>
>> ACK with nit fixed.
>>
> norelabel indicates that the Physical disk files/images should not be
> relabeled.  When we create a tmpfs file system lxc containers always need to
> set an initial label on them.

Now I wonder whether this flag should not be enforced in case of 
non-tmpfs file system (LXC) and should be enforced in other cases 
(Qemu). Maybe we need to pass a flag to this function indicating tmpfs ?

    Stefan




More information about the libvir-list mailing list