Quoting CAI Qian ([email protected]): > Hi, > > > --- On Wed, 1/28/09, Serge E. Hallyn <[email protected]> wrote: > > > From: Serge E. Hallyn <[email protected]> > > Subject: Re: [LTP] [PATCH] proc01: SELinux with attr/* Interface - version 2 > > To: "CAI Qian" <[email protected]> > > Cc: "Kamalesh Babulal" <[email protected]>, > > [email protected], [email protected], [email protected], > > [email protected] > > Date: Wednesday, January 28, 2009, 10:57 PM > > 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? > > > > Yes, Stephen Smalley from National Security Agency of U.S. told it > means "security modules (e.g. capability) don't support any of those > interfaces", so if another errno is returned, it should be brought up > to attention.
Obviously the correct behavior depends upon the security subsystem, but you're finagling the checks into fs-specific checks. It seems to me that if you're going to check for correct return values from these functions, you should do so under testcases/kernel/security. -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
