[Devel] [PATCH RHEL9 COMMIT] kernfs/ve: fix strange ve_is_super check in kernfs_d_visible

[Konstantin Khorenko]

The commit is pushed to "branch-rh9-5.14.0-4.vz9.12.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh9-5.14.0-4.vz9.12.5
------>
commit c3b1a20b202f33521df8d8acfac1f89bd8f6fecd
Author: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
Date:   Wed Feb 2 17:13:39 2022 +0300

    kernfs/ve: fix strange ve_is_super check in kernfs_d_visible
    
    Before this patch the check in kernfs_d_visible() was strange, it
    checked ve_is_super(kernfs_super_info->ve) where ->ve is set once when
    mounting new superblock (see sysfs_set_ve_perms). So if sysfs was first
    mounted from ve0 the check would always pass and kernfs_d_visible() will
    return true, even if sysfs for some reason is accessed from veX. Meaning
    that if host sysfs is bindmounted to veX, it would show it's full
    content without bothering about veX ve.sysfs_permissions setup.
    
    Similar case is when sysfs of veX by accident or intentionally was
    first mounted from ve0, it then due to this check would show full
    content, again not bothering about ve.sysfs_permissions when accessed
    from container.
    
    And the opposite case when veX sysfs was first mounted from veX, accesses
    from ve0 would be restricted via ve.sysfs_permissions. Even though ve0
    does not have it's own ve.sysfs_permissions, it just will use
    ve.default_sysfs_permissions instead as kmapset_get_value() has a
    fallback. Meaning that host could not access hidden parts of container
    sysfs, and that can be a problem if we would need to configure such a
    part from host (e.g. /sys/fs/nfs/net/nfs_client/identifier).
    
    So let's just use kernfs_ve_allowed() in kernfs_d_visible() similar to
    what we do in kernfs_ve_permission() (when approving access to files),
    that's a perfectly logical and symmetric solution.
    
    Feature: ve/sysfs: sysfs access virtualization
    
    https://jira.sw.ru/browse/PSBM-137997
    Fixes: b8b3b9943017 ("ve/kernfs: hide forbidden entries in container")
    Fixes: a4ceab46e634 ("kernfs/ve: ignore kernfs 've_perms_map' in cgroups.")
    Signed-off-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
---
 fs/kernfs/ve.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/fs/kernfs/ve.c b/fs/kernfs/ve.c
index 0c4c28cc745d..19cf20158cd1 100644
--- a/fs/kernfs/ve.c
+++ b/fs/kernfs/ve.c
@@ -101,15 +101,10 @@ void kernfs_put_ve_perms(struct kernfs_node *kn)
 
 bool kernfs_d_visible(struct kernfs_node *kn, struct kernfs_super_info *info)
 {
-	struct ve_struct *ve = info->ve;
 	struct kernfs_node *tmp_kn = kn;
 
-	/* Non-containerized fs */
-	if (!ve)
-		return true;
 
-	/* Host sees anything */
-	if (ve_is_super(ve))
+	if (kernfs_ve_allowed(kn))
 		return true;
 
 	/* Entries with namespace tag and their sub-entries always visible */
@@ -123,15 +118,6 @@ bool kernfs_d_visible(struct kernfs_node *kn, struct kernfs_super_info *info)
 	if (kernfs_type(kn) == KERNFS_LINK)
 		kn = kn->symlink.target_kn;
 
-	/*
-	 * Some systems that are built on top of kernfs might
-	 * not want to use ve_perms_map (cgroup is an example)
-	 * so they leave ve_perms_map uninitialized.
-	 * For them we just true.
-	 */
-	if (!kn->ve_perms_map)
-		return true;
-
 	return !!kmapset_get_value(kn->ve_perms_map,
 				   kernfs_info_perms_key(info));
 }