Re: [PATCH] selinux: Don't fail RestoreAll if file doesn't have a default label

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/2012 10:55 AM, Cole Robinson wrote:
> On 10/23/2012 06:56 AM, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 10/22/2012 04:13 PM, Cole Robinson wrote:
>>> 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
>>> 
>> Another option would be to get the label before the virtual machine
>> starts and then restore it to the old label, if we have kept the label
>> around.
>> 
> 
> That would take some work. I think it's fair to say that if users have a
> file with a non default label, and they want it restored after svirt usage,
> they just install their own custom policy so our equivalent of 'restorecon'
> does the right thing.
> 
> - Cole
> 
One other option would be to grab the label before you change it and then set
it back you are done.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCH6WsACgkQrlYvE4MpobPnQACfWXTb/5Gff2V012e9wdN8B7Xs
AxEAoNeEzC/tdVOyLS/d8ZD6W0wkIgY6
=h9TN
-----END PGP SIGNATURE-----

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]