Messages in this thread | | | Date | Sun, 28 Oct 2007 14:46:36 +0200 | From | "Ahmed S. Darwish" <> | Subject | Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel |
| |
On 10/28/07, Al Viro <viro@ftp.linux.org.uk> wrote: > On Sat, Oct 27, 2007 at 11:01:12AM +0200, Ahmed S. Darwish wrote: > > The problem here (As discussed in private mails) is that the for loop > > assumes that the beginning of given user-space buffer is the beginning > > of a rule. This leads to situations where the rule becomes "ecret 20", > > or "cret 20" instead of "Secret 20". Big input buffers/files leads > > smack to recieve a rule like "Secret 20" in fragmented chunks like: > > > > write("<lots of rules before ours>\nSec", ..) > > write("r", 1, ..) > > write("et 20\n<remaing rules after ours>", ..) > > > > Parsing a rule in such tough conditions in _kernel space_ is very > > hard. I began to feel that it will be much easier if we do the parsing > > in a userspace utility and let smack accept only small buffers (80 char). > > For crying out louf, all it takes is a finite state machine... BTW, folks, > your parser *and* input language suck. Really. Silently allowing noise > is Dumb(tm). >
Ehem .., I really thought about the FSM thing but I thought it won't be possible with concurrent writes (forgetting that several related writes is done in one open(),release() session and we can lock writes in open()).
<Getting back to coding>
-- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |