Hi,
----- Original Message ---- > > > > > > > > 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 > > Well if he really wants to test the procfs part of it, then he should > be testing reading and writing of various sizes... But no. > There is a switch in proc01 test to pass a specified length of read buffer. Those entries can be tested the similar way by using that switch. > > I think his concern is that it will obscure an actual bug in SELinux in > > the future. > > I thought he was worried not about any SELinux bugs, but bugs in > the way procfs passes data to/from selinux. > Well, this test more looks like an end-user testing, so it should not concern too much about how internal working of those entries. From a end-user or test designer's expectation, those proc filesystems entries are present on the system, and have right permission to be able to read. If the system with SELinux is enabled, it expects the read(2) return 0 probably by using various length of read buffers. CAI Qian > > 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. > > Ok, I'm sorry, I'm dragging this out. I'll stop, I promise. > > -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
