On 10/11/23 16:31, Sergey Mironov wrote:

In version 0.10.0-rc0 (https://github.com/libvirt/libvirt/blob/v0.10.0-rc0/src/security/security_se... ) 11 years ago, the virSecuritySELinuxSetFileconHelper function appeared, which returned 1 if the optional is true. Considering that at the moment the virSecuritySELinuxSetFilecon function (by definition) can only return 0 or -1, I suggest removing the "dead code" in the current patch.

Co-developed-by: sdl.qemu <sdl.qemu@linuxtesting.org> Signed-off-by: Sergey Mironov <mironov@fintech.ru> --- src/security/security_selinux.c | 11 ----------- 1 file changed, 11 deletions(-)

diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 7914aba84d..a7abab9cf8 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -1988,17 +1988,6 @@ virSecuritySELinuxSetImageLabelInternal(virSecurityManager *mgr, ret = virSecuritySELinuxSetFilecon(mgr, path, use_label, remember); }

- if (ret == 1 && !disk_seclabel) { - /* If we failed to set a label, but virt_use_nfs let us - * proceed anyway, then we don't need to relabel later. */ - disk_seclabel = virSecurityDeviceLabelDefNew(SECURITY_SELINUX_NAME); - if (!disk_seclabel) - return -1; - disk_seclabel->labelskip = true; - VIR_APPEND_ELEMENT(src->seclabels, src->nseclabels, disk_seclabel); - ret = 0; - } - return ret; }

At this point, the @ret variable can be removed as well. But I can live with that. What I can't live with is the commit message. Firstly, there's no need to link the source file if you mention the actual commit that introduced the function: 12b187fb956bffbc67a090dcda89e66450503a4e and to make the hash more readable, just use git-describe (which in this particular case yields some CVE-* tag, so pass --match=v\* to get v0.10.0-rc0~108). Nit-pick - mentioning the commit when a function was introduced is good, but also, we are probably more interested in what commit turned these lines into a dead code. Because without that the first piece of information makes a great sensation (we have a dead code for 11 years!, which is obviously not true). Then there are more rigid customs we tend to hold: 1) if you look at 'git log --oneline' you'll see that majority (if not all) commits are prefixed with something (usually the module they change). Thus in this case it should have been "selinux: ". 2) Continuing with git log - "selinux: Checking the value ..." does not really describe what's happening. You are dropping the check, not introducing it. I'm sorry if I sound too picky, but these rules help greatly downstream maintainers when they need to figure out what each commit does. Anyway, I'm fixing the commit message and pushing. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal