Quoting CAI Qian (caiq...@cclom.cn):
> --- On Wed, 1/28/09, CAI Qian <caiq...@cclom.cn> wrote:
> Here is the link for the email from Stephen Smalley that I was refer
> to,
> http://article.gmane.org/gmane.linux.ltp/7324

The patch you sent doesn't do what he suggests though.  He is saying
to ignore the case where the files return data, warn and then ignore
the case where it returns -EINVAL, and return a fatal error if
another error is returned.  Notice that should involve no checks
for whether selinux is enabled, of which your patch had many.

The only potential problem with Stephen's suggestion that I see would be
that an LSM may return -EPERM or some other error as part of its
implementation.  Not sure if that would become a problem in practice
or not.

So I would still suggest ignoring these files in proc01.c altogether,
and starting with a simple test under testcases/kernel/security.  If
that test becomes more baroque over time to reflect smack/tomoyo/etc
implementation details, then at least it's in the right place.

But I objected to your last patch because of all of the selinux-specific
code in what should be a simple procfs functionality test.  If you
implement precisely what Stephen suggested then I'll certainly ack
it.

thanks,
-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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to