From: Serge E. H. <se...@us...> - 2009-01-29 16:52:59
|
Quoting CAI Qian (ca...@cc...): > Hi, > > > > ----- Original Message ---- > > From: Kamalesh Babulal <kam...@li...> > > To: Serge E. Hallyn <se...@us...> > > Cc: CAI Qian <ca...@cc...>; ltp...@li...; sd...@ty...; su...@li...; aa...@li... > > 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 |