On Tue, Apr 15, 2025 at 10:06 AM Li Lingfeng <lilingfeng3@xxxxxxxxxx> wrote: > > Hi, > Thank you for reporting this issue and sharing the detailed reproducer. > Apologies for the gap in my knowledge regarding security_label. > Would need some time to study its implementation in the security subsystem. > > To begin validating the problem, I attempted to run the reproducer on > Fedora 26(with kernel -- master 8ffd015db85f). However, I didn't observe > the reported mislabeling of the root directory. Hm... Fedora 26 is *very* outdated and not maintained any more - I'd recommend using 41, which is the current latest stable release. Hard to say if it affects the reproducibility of this bug, but it's always possible that userspace is also somehow involved. > > The modifications introduced by commit fc2a169c56de specifically affect > scenarios where the /proc/net/rpc/xxx/flush interface is frequently > invoked within a 1-second window. During the reproducer execution, I > indeed observed repeated calls to this flush interface, though I'm > currently uncertain about its precise impact on the security_label > mechanism. > [ 124.108016][ T2754] call write_flush > [ 124.108878][ T2754] call write_flush > [ 124.147886][ T2757] call write_flush > [ 124.148604][ T2757] call write_flush > [ 124.149258][ T2757] call write_flush > [ 124.149911][ T2757] call write_flush > > Once I have a solid understanding of the security_label mechanism, I will > conduct a more thorough analysis. I'm not sure how the two affect each other either... It almost looks like the last mount command somehow ends up mounting the "old" export without security_label in some cases, even though the exportfs commands that re-export the dir without security_label had completed successfully by that time. Thank you for looking into it! > > Best regards, > Li Lingfeng > > 在 2025/4/14 18:53, Ondrej Mosnacek 写道: > > Hello, > > > > I noticed that the selinux-testsuite > > (https://github.com/SELinuxProject/selinux-testsuite) nfs_filesystem > > test recently started to spuriously fail on latest mainline-based > > kernels (the root directory didn't have the expected SELinux label > > after a specific sequence of exports/unexports + mounts/unmounts). > > > > I bisected (and revert-tested) the regression to: > > > > commit fc2a169c56de0860ea7599ea6f67ad5fc451bde1 > > Author: Li Lingfeng <lilingfeng3@xxxxxxxxxx> > > Date: Fri Dec 27 16:33:53 2024 +0800 > > > > sunrpc: clean cache_detail immediately when flush is written frequently > > > > It's not immediately obvious to me what the bug is, so I'm posting > > this to relevant people/lists in the hope they can debug and fix this > > better than I could. > > > > I'm attaching a simplified reproducer. Note that it only tries 50 > > iterations, but sometimes that's not enough to trigger the bug. It > > requires a system with SELinux enabled and probably a policy that is > > close enough to Fedora's. I tested it on Fedora Rawhide, but it should > > probably also work on other SELinux-enabled distros that use the > > upstream refpolicy. > > > -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
