Quoting CAI Qian ([email protected]): > Kamalesh Babulal, well, my approach is that anyone who cares about > AppArmor can add a list of files should work to the code. it is fair that if > different LSMs behave differently, we'll need different lists > (selinux_should_work and apparmor_should_work) to deal with them. > > > To make it > > generic can we > > just skip reading the list of files, if they return EINVAL > > or else we > > have to support checking of different LSM's and add > > support for each of > > them individually. > > > > Yes, but then you will still need to treat different LSMs differently. > > > Agree that the coverage of the testcase is going to be > > reduced. It will be > > reduced more because the list which we are taking care is > > incomplete, > > Which ones are missing -- should return EINVAL with SELinux > disabled? > > > we could need to add other files to the list like nfs to be > > skipped. > > Sending another patch which will ignore the file if it > > returns EINVAL or else > > throw warning. > > This patch won't able to catch attr/* entries return > EINVAL while SELinux is enabled. It does not look like a good > approach to me, because it is a test coverage regression. > > CAI Qian
So, just to try and think through this... If no LSM is enabled, the files should return -EINVAL. If they don't return -EINVAL, is that a situation we care about? What would it mean? If that is not a situation we care about, then we should simply ignore the files if selinux is disabled. If selinux is enabled, the user can run the selinux testsuite and it can test for proper return values. -serge ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
