Hi,
----- Original Message ---- > From: Stephen Smalley <[email protected]> > To: Serge E. Hallyn <[email protected]> > Cc: CAI Qian <[email protected]>; [email protected]; > [email protected] > Sent: Friday, January 30, 2009 2:58:48 AM > Subject: Re: [LTP] [PATCH] proc01: SELinux with attr/* Interface - version 2 > > > > > > > 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. > Exactly. The test should be able to run in different testing environment if possible, and expect correct results according to that particular environment if they differ. The test code just need a little bit careful to make it not overkill to maintain. > > > > > > 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. > My main concerns of Kamalesh's patch are, * reduce testing coverage of the test with SELinux enabled testing environment, because all reads of attr/* files are not flagged EINVAL as errors any more. * false positive and misleading messages may happen on SELinux-enabled machine. If attr/* files returns EINVAL while SELinux is enabled happens in the future, it can be a bug in kernel or SELinux or both. > 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. > I agree. I suppose that proc01 is mainly to test how kernel behaves when to read those entries -- may use various length read buffers etc. Of course, people might use it differently. Someone may use it as a latency kernel for realtime kernel testing. It would be nice to keep that flexibiltiy other than saying that this test must be run with a particular kernel or LSM configuration. CAI Qian > -- > 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
