Hi,
--- On Fri, 1/23/09, Kamalesh Babulal <kamal...@linux.vnet.ibm.com> wrote: > From: Kamalesh Babulal <kamal...@linux.vnet.ibm.com> > Subject: Re: [LTP] proc01 failures with selinux disabled > To: ltp-l...@lists.sf.net > Cc: caiq...@cclom.cn, se...@us.ibm.com, subr...@linux.vnet.ibm.com, > aar...@linux.vnet.ibm.com > Date: Friday, January 23, 2009, 3:36 PM > * CAI Qian <caiq...@cclom.cn> [2009-01-22 09:17:02]: > > > Hi, > > > > > > --- On Fri, 1/23/09, Serge E. Hallyn > <se...@us.ibm.com> wrote: > > > > > From: Serge E. Hallyn <se...@us.ibm.com> > > > Subject: Re: [LTP] proc01 failures with selinux > disabled > > > To: "CAI Qian" <caiq...@cclom.cn> > > > Cc: ltp-l...@lists.sf.net > > > Date: Friday, January 23, 2009, 12:00 AM > > > Quoting CAI Qian (caiq...@cclom.cn): > > > > Hi, > > > > > > > > > > > > --- On Thu, 1/22/09, Subrata Modak > > > <subr...@linux.vnet.ibm.com> wrote: > > > > > > This approach will skip the > failures that > > > those > > > > > entries return EINVAL > > > > > > while SELinux is enable. You can > check if > > > SELinux is > > > > > enable or not, and > > > > > > then add then to something like > > > > > known_issue_without_selinux table. > > > > > > > > > > > > I'd suggest to add some > comments or > > > TINFO at the > > > > > beginning of it to > > > > > > state that the test should be run > with > > > SELinux enable. > > > > > > > > > > If the test cannot run with Selinux > Enabled, then > > > exit with > > > > > TCONF and > > > > > proper message. > > > > > Report appropriate info post testing > when Selinux > > > is > > > > > actually enabled. > > > > > > > > > > > > > Actually, it is not that it cannot be run > with SELinux > > > disabled. It > > > > can, and there is no enforcement. I > don't want to > > > block the test to > > > > run if SELinux is disabled if anybody want > to have a > > > try. > > > > > > > > However, those EINVAL failures are unclear > to me that > > > if they are > > > > kernel bugs or not, > > > > > > No if there is no LSM then the /proc/$$/attr/ > files will > > > return > > > -EINVAL, that's correct behavior. Now > it's not > > > just SELinux - > > > Smack and AppArmor (and probably tomoyo too) will > define > > > some > > > or all of the hooks to write data to those files. > > > > > > So for /proc/$$/attr/* it's perhaps best to > have > > > generic ltp > > > ignore them, and have the lsm-specific tests test > their > > > behavior. Or, detect if no lsm is loaded > (somehow) and, > > > only in that case, make sure that -EINVAL IS in > fact > > > returned, > > > else there might be a problem. > > > > > > > Those are all sound good for me. If go for the later, > I am not sure if > > the test with Smack or AppArmor enabled will return > the same result > > as SELinux. > > > > > The other files (i.e. /proc/$$/tasks/pid/mem) > I'm not > > > so sure > > > about. > > > > At least, that is how it behaves for RHEL4, RHEL5, and > upstream > > kernels. In the past, there was a small bug which > changed the behaviour > > from -EIO to -EINVAL for RHEL4 kernel, which caused > gcore command have > > a significant performance drop for certain > multi-thread programs. The > > original bug is private due to customer information > there, but there > > is a duplicated public bug for it which contains a > little bit history, > > > > https://bugzilla.redhat.com/show_bug.cgi?id=460106 > > > > CAI Qian > > > > > > > > > so if you want to get away with those errors > when > > > > SELinux is disabled, you can probably fix > the kernel > > > bugs, ignore them > > > > or put them to the SELinux off known issue > list, as I > > > mentioned before. > > > > > > > > Because everybody in Red Hat is trained that > any test > > > should be run > > > > with SELinux enabled, it is off my interest > to make > > > that change. > > > > We can ignore reading the files, which are dependent on the > LSM or > we can add them to the know_issue list. > > Impact: Skip the reading of file dependent on LSM > > When there is no LSM loaded, reading /proc/$$/attr/ files > returns > -EINVAL, skip reading those file with TWARN > > Signed-off-by: Kamalesh Babulal > <kamal...@linux.vnet.ibm.com> > --- > testcases/kernel/fs/proc/proc01.c | 19 > ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > Index: b/testcases/kernel/fs/proc/proc01.c > =================================================================== > --- a/testcases/kernel/fs/proc/proc01.c > +++ b/testcases/kernel/fs/proc/proc01.c > @@ -1,6 +1,6 @@ > /* > * proc01.c - Tests Linux /proc file reading. > - * > + * > * Copyright (C) 2008, 2009 Red Hat, Inc. > * Copyright (C) 2001 Stephane Fillod > <f4...@free.fr> > * > @@ -100,6 +100,15 @@ const char error_nonblock[][PATH_MAX] > = > "" > }; > > +/* Skip files, which are dependent on the LSM (Linux > Security Module) > + * loaded, if no LSM is load, these files return -ENIVAL. > */ > +const char error_nolsm[][PATH_MAX] = > +{ > + "/proc/self/attr/*", > + "/proc/self/task/[0-9]*/attr/*", > + "" > +}; > + > /* Verify expected failures, and then let the test to > continue. */ > int found_errno(const char *syscall, const char *obj, int > tmperr) > { > @@ -283,6 +292,14 @@ int readproc(const char *obj) > return 0; > } > > + /* Skip files which depends on LSM */ > + for (i = 0; error_nolsm[i][0] != '\0'; > i++) > + if (!fnmatch(error_nolsm[i], obj, > FNM_PATHNAME)) { > + tst_resm(TWARN, "%s: is LSM depedent.", > obj); > + close (fd); > + return 0; > + } > + > nread = 1; > while (nread > 0) { > nread = read(fd, buf, buffsize); Again, the patch reduces the test coverage for reading of those entries entirely. In addition, the warning is probably not appropriate here, because there is nothing users can do about it. How about skip those files only when LSM is disabled? CAI Qian > -- > Thanks & Regards, > Kamalesh Babulal, > Linux Technology Center, > IBM, ISTL. ------------------------------------------------------------------------------ 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 Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
