On Thu, 2009-01-29 at 12:23 -0600, Serge E. Hallyn wrote: > Quoting CAI Qian ([email protected]): > > Hi, > > > > 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... > > > > > > > No, they do not belong there, because we are focus on testing of proc > > filesystem here. The test case here should not care about the content it > > read, but rather what the kernel behaves when to read those files. > > Then the dummy lsm I suggested is the only way to really test what you > want :)
That's not really a serious suggestion, right? If the proc01 test cannot be dependent on the presence/absence of any given security module (like SELinux), then it cannot be dependent on a fake test security module either as that would preclude running the test while SELinux was in fact enabled. > > > > 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. > > > > > > > Stephen's suggestion is something we should take. I agree Kamalesh's > > patch has included his suggestion. Unfortunately, there are other issues > > with Kamalesh's patch that have been pointed out in the last email. > > Sorry, I've looked back through the thread, but don't see the other > issues you're talking about. I think his concern is that it will obscure an actual bug in SELinux in the future. I don't care strongly about it either way - the selinux testsuite is what you should be using to exercise SELinux, and just booting and logging into a SELinux-enabled system will exercise many if not all of those interfaces. -- Stephen Smalley National Security Agency ------------------------------------------------------------------------------ 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
