* is there any plan to support BSD accept filter?
@ 2005-01-14 20:51 KyoungSoo Park
2005-01-14 22:05 ` Stephen Hemminger
0 siblings, 1 reply; 4+ messages in thread
From: KyoungSoo Park @ 2005-01-14 20:51 UTC (permalink / raw)
To: netdev
Hi,
I just want to ask a quick question.
Is there any plan to support FreeBSD-like accept filter
(http://www.freebsd.org/cgi/man.cgi?query=accf_http) for linux?
If not, is there any glaring reason why?
Thanks,
KyoungSoo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is there any plan to support BSD accept filter?
2005-01-14 20:51 is there any plan to support BSD accept filter? KyoungSoo Park
@ 2005-01-14 22:05 ` Stephen Hemminger
2005-01-15 2:22 ` KyoungSoo Park
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Hemminger @ 2005-01-14 22:05 UTC (permalink / raw)
To: KyoungSoo Park; +Cc: netdev
If you want to do these kind of stateful hacks, why not build a
netfilter module to do it?
--
Stephen Hemminger <shemminger@osdl.org>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is there any plan to support BSD accept filter?
2005-01-14 22:05 ` Stephen Hemminger
@ 2005-01-15 2:22 ` KyoungSoo Park
2005-01-16 14:43 ` jamal
0 siblings, 1 reply; 4+ messages in thread
From: KyoungSoo Park @ 2005-01-15 2:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
yes. I agree that maybe an ugly hack to put that in the kernel.
What I want to do is to support such feature leaving as little footprint
as possible in the kernel, but specify whatever flexible policy you want
in the user level.
I'm not sure netfilter module is the right place because it seems I need
to do packet by packet processing, but I want to deal with a little higher
level than that as a start. (I'm not familar with netfilter, so please correct
me if I'm wrong.)
Anyway, thanks for your response.
KyoungSoo
Stephen Hemminger wrote:
>If you want to do these kind of stateful hacks, why not build a
>netfilter module to do it?
>
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is there any plan to support BSD accept filter?
2005-01-15 2:22 ` KyoungSoo Park
@ 2005-01-16 14:43 ` jamal
0 siblings, 0 replies; 4+ messages in thread
From: jamal @ 2005-01-16 14:43 UTC (permalink / raw)
To: KyoungSoo Park; +Cc: Stephen Hemminger, netdev
Seems easy to do if you can muck with the security hooks.
The selinux folkk already have a monopoly on all those hooks.
Look at selinux and security_socket_accept() and how you can hook up
to it. You probably wanna worry about security_socket_recvmsg() and
security_socket_post_accept()
Dont ask me - look at the code and visit their docs. As a warning those
hooks are pretty stupid (what a waste of potential) so you will have to
sweat a little hacking them to maintain state.
cheers,
jamal
On Fri, 2005-01-14 at 21:22, KyoungSoo Park wrote:
> yes. I agree that maybe an ugly hack to put that in the kernel.
> What I want to do is to support such feature leaving as little footprint
> as possible in the kernel, but specify whatever flexible policy you want
> in the user level.
> I'm not sure netfilter module is the right place because it seems I need
> to do packet by packet processing, but I want to deal with a little higher
> level than that as a start. (I'm not familar with netfilter, so please correct
> me if I'm wrong.)
>
> Anyway, thanks for your response.
>
> KyoungSoo
>
>
> Stephen Hemminger wrote:
>
> >If you want to do these kind of stateful hacks, why not build a
> >netfilter module to do it?
> >
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-01-16 14:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-14 20:51 is there any plan to support BSD accept filter? KyoungSoo Park
2005-01-14 22:05 ` Stephen Hemminger
2005-01-15 2:22 ` KyoungSoo Park
2005-01-16 14:43 ` jamal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).