On Thu, Aug 22, 2019 at 05:19:05PM +0200, Michal Privoznik wrote:
The only thing that the @optional argument does is that it makes the function return 1 instead of 0 if setting SELinux context failed in a non-critical fashion. Drop the argument then and return 1 in that case. This enables caller to learn if SELinux context was set or not. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/security/security_selinux.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 0523613d4a..35385f4a23 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -1261,19 +1261,23 @@ virSecuritySELinuxGetProcessLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED, * virSecuritySELinuxSetFileconImpl: * @path: path to the file to set context on * @tcon: target context to set - * @optional: whether to treat errors as fatal * @privileged: whether running as privileged user * * Set @tcon SELinux context on @path. If unable to do so, check SELinux * configuration and produce sensible error message suggesting solution. + * It may happen that setting context fails but hypervisor will be able to + * open the @path successfully. This is because some file systems don't + * support SELinux, are RO, or the @path had the correct context from the + * start. If that is the case, a positive one is returned. * * Returns: -1 if failed to set context and SELinux is in enforcing mode - * 1 if failed to set context and @optional is true - * 0 otherwise. + * 1 if failed to set context, + * 0 if context was set successfully.
This is where this does not agree with following patches. The code works, but
the comment is still a bit unclear, even though it is at least a tad less
confusing (well, the code doesn't really help with constructing a proper
documentation).
I would go with:
* Returns: 0 if context was set successfully
* 1 if setting the context failed in a non-critical fashion
* -1 in case of error
or something along the lines of the above, critical change being the description
of return value 1. Feel free to split the change between PATCH 1 and this one
in a way that makes sense or just squash them together, that's fine as well.
If you go with my suggestion for the comment, then:
Reviewed-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
