Quoting CAI Qian ([email protected]): > Hi, > > > > ----- Original Message ---- > > From: Kamalesh Babulal <[email protected]> > > To: Serge E. Hallyn <[email protected]> > > Cc: CAI Qian <[email protected]>; [email protected]; [email protected]; > > [email protected]; [email protected] > > Sent: Thursday, January 29, 2009 6:21:49 PM > > Subject: Re: [LTP] [PATCH] proc01: SELinux with attr/* Interface - version 2 > > > > > > We can just add the files related to LSM, to known failure list. We already > > check for their return value, if not EINVAL report test failure or else > > skip. > > I am afraid this patch is incorrect. It is total valid that people may want > to run this > test in a SELinux enabled environment. For example, after applied the patch, > we > might see some day, > > INFO: /proc/self/attr/exec: EINVAL: known failure > > That is just incorrect, because this entry should return successfully in such > a testing > environment setup. > > It is also fairly normal that in order to support a different testing > environment, we > may add some conditional compilation code for then. > > In addition, for people like me have used the previous version of the test in > a > SELinux enabled environment, they will lost that kind of testing coverage for > those entries (only return successfully), which is bad from the testing point > of > view. > > You can argue that this has already been testing in SELinux test suite, but > it looks
Yup. > to me the test here has a different testing focus -- try to read every entry > in /proc > filesystem. Those entries belong to this filesystem, so we'll read them the > same > way. Who knows if those entries will not give us a hang or panic or behaving > badly with certain read buffers? SELinux test suite may or may not catch those > kind of bugs. Then add tests in there... In fact, the logical course given your concern would be to write a kernel module defining an LSM allowing random long write to and reads from /proc/$$/attr/ so you can test the procfs bits of that API (if you could still write an LSM as a module :). It should be doable to push a 'debug' LSM into the upstream kernel which just serves to facilitate such testing. Anyway I've made my own position clear, and I think Kamalesh's patch implements precisely what Stephen suggested. thanks, -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
