On 10/22/2012 11:51 AM, Eric Blake wrote:
On 10/21/2012 02:44 PM, Cole Robinson wrote:
> When restoring selinux labels after a VM is stopped, any non-standard
> path that doesn't have a default selinux label causes the process
> to stop and exit early. This isn't really an error condition IMO.
>
> Of course the selinux API could be erroring for some other reason
> but hopefully that's rare enough to not need explicit handling.
>
> Common example here is storing disk images in a non-standard location
> like under /mnt.
> ---
> src/security/security_selinux.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
> index eee8d71..7681f1b 100644
> --- a/src/security/security_selinux.c
> +++ b/src/security/security_selinux.c
> @@ -936,7 +936,11 @@ virSecuritySELinuxRestoreSecurityFileLabel(const char *path)
> }
>
> if (getContext(newpath, buf.st_mode, &fcon) < 0) {
> + /* Any user created path likely does not have a default label,
> + * which makes this an expected non error
> + */
> VIR_WARN("cannot lookup default selinux label for %s", newpath);
> + rc = 0;
In the case where there is no default label to restore, shouldn't we
still be removing our sVirt label rather than just ignoring the failure
but leaving our label intact?
I sent other mails about that. But since that topic is kind of a side point,
is this patch okay to commit in the interim? It should only improve our
behavior WRT restoring default labels, since we will now continue on even if
something in the chain doesn't have a default.
Thanks,
Cole