On Fri, 8 Jan 2010 00:05:56 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Thu, Jan 07, 2010 at 09:18:32AM -0500, Jeff Layton wrote: > > On Wed, 6 Jan 2010 15:33:13 -0500 > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > > On Wed, Jan 06, 2010 at 03:22:55PM -0500, Chuck Lever wrote: > > > > My original idea was that this facility would be a set of smaller unit > > > > tests. Since some of statd/sm-notify is now broken out into libraries, I > > > > think that makes it a little easier to craft targeted tests that don't > > > > require a full-blown statd running to carry out (Of course, that's > > > > speculation; I could be wrong, and Jeff has kindly set up the code for us > > > > to test this theory!). > > > > > > > > The old code has a statd simulator that doesn't require root, and uses > > > > its own RPC program number. It might be reasonable to adopt that > > > > approach instead of using the real statd, for some test cases. > > > > > > Like I say, it might be nice to be able to add even more intrusive tests > > > (e.g. that modify the exports and then test the results over "lo" with > > > the kernel client), so I'm actually happy Jeff says he's not bending > > > over backwards to make the tests unprivileged. > > > > > > > The root privs problem is definitely a valid concern. > > > > After thinking about this problem I think the thing to do is > > probably to create a "run as root" script that starts up statd (for > > now) and other daemons (eventually). make check can then prompt the > > user to inspect and run that script as root and then hit return when > > it's ok to proceed. > > > > That should allow someone to run most of the actual test code as an > > unprivileged user. I'll plan to incorporate something like this in the > > next respin. > > That sounds complicated. And, as I said above, we might some day like > to include tests where the privileged stuff makes up the body of the > test. > > Why not just "the tests you are about to run need root privileges, and > will start and stop statd; continue (y/n)?" > Ok. Most statd tests probably won't need root privs, but it makes sense that other tests eventually will. That's certainly a simpler approach. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
