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 don't know if we can just 'remove' a label, we have to replace it with a different label, right? If I create a file under /mnt/foo the catch all label is unconfined_u:object_r:file_t:s0 but not sure if we can hardcode that. dwalsh, is there a way to programmatically determine the fallback default label? - Cole