On Thu, May 6, 2010 at 10:55 AM, Serge E. Hallyn <[email protected]> wrote: > Quoting Garrett Cooper ([email protected]): >> On Thu, May 6, 2010 at 6:53 AM, Serge E. Hallyn <[email protected]> wrote: >> > Quoting Garrett Cooper ([email protected]): >> >> On May 5, 2010, at 11:56 PM, Subrata Modak wrote: >> >> >> >> > Subject: LTPś sysctl03 test fails >> >> > >> >> > Issues Description Below: >> >> > ===================================== >> >> > # ./runltp -s sysctl03 >> >> > <<<test_output>>> >> >> > sysctl03 1 TFAIL : Expected EPERM (1), got 13: Permission denied >> >> > sysctl03 2 TFAIL : Expected EPERM, got 13 >> >> > sysctl03 1 TFAIL : Expected EPERM (1), got 13: Permission denied >> >> > <<<execution_status>>> >> >> > initiation_status="ok" >> >> > duration=0 termination_type=exited termination_id=1 corefile=no >> >> > cutime=0 cstime=0 >> >> > <<<test_end>>> >> >> >> >> Already known and recently discussed. >> > >> > Not only can things move glacially in kernel-land, but decisions not >> > yet implemented can be changed. >> > >> > In the meantime, the sysctl's sit there as a potential subject for >> > exploitation. >> > >> > So not meaning to be argumentative for its own sake, I nevertheless >> > think it's better to fix the test than either to ignore or remove >> > it. Two untested patches below - the one just replaces EPERM with >> > EACCESS. The other removes the (imo misuided) notion that we can >> > guess at the failing errno. >> >> Except that the documentation (manpages) should explicitly state what >> the failing conditions are for any given libcall and syscall. If not, >> the Linux kernel devs and documentation team have failed to do their >> job. > > So since we're all member of the doc team, send a patch for sysctl(2) > manpage ERRORS section :) > > (mtk cc:d as this is probably news to him)
I already have a bug outstanding for it: https://bugzilla.kernel.org/show_bug.cgi?id=15446 >> > An LSM could choose to return -EPERM >> > after all, or perhaps even something different. The thing that >> > should scare us is if the call succeeds. If we give any false >> > positives, then true positives will seem less scary. >> >> This will fail on older kernels as sysctl(2) always returned EPERM due > > Sorry - what will fail? Read through the link, and you will understand why your new proposed patch with fail with a false negative. > I think you're saying the first patch will, and I agree, which is why > I advocate the second one i pasted in. > >> to the way it was improperly designed. Please see the previous thread >> for more info: http://lkml.org/lkml/2010/3/4/354 Thanks, -Garrett ------------------------------------------------------------------------------ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
