> On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
> > Hi
> > printk_ratelimit function takes care of flooding the
> > syslog. due to printk_ratelimit function syslog will not be flooded
> > anymore. as soon as administrator gets this message, he can take
> > action against that user (may be block user's access on server). i
> > think the my fork patch is very useful and helps administrator lot.
> > i would also like to mention that in some of the cases
> > ulimit solution wont work. in that case fork bombing takes the machine
> > and server needs a reboot. i am sure in that situation this printk
> > statement helps administrator to know what has happened.
>
> If ulimit "wont work" in some situations, how is it going to trigger this printk?
> (When doesn't it work?)
>
> > Anand
> >
> > On 8/24/07, Chris Snook <csnook@redhat.com> wrote:
> >> Krzysztof Halasa wrote:
> >> > Hi,
> >> >
> >> > "Anand Jahagirdar" <anandjigar@gmail.com> writes:
> >> >
> >> >> I am forwarding one more improved patch which i have modified as
> >> >> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
> >> >> i have added one more if block to check hard limit. how good it is?
> >> >
> >> > Not very, still lacks "#ifdef CONFIG_something" and the required
> >> > Kconfig change (or other runtime thing defaulting to "no printk").
> >>
> >> Wrapping a single printk that's unrelated to debugging in an #ifdef
> >> CONFIG_* or a sysctl strikes me as abuse of those configuration
> >> facilities. Where would we draw the line for other patches wanting to
> >> do similar things?
> >>
> >> I realized that even checking the hard limit it insufficient, because
> >> that can be lowered (but not raised) by unprivileged processes. If we
> >> can't do this unconditionally (and we can't, because the log pollution
> >> would be intolerable for many people) then we shouldn't do it at all.
> >>
> >> Anand -- I appreciate the effort, but I think you should reconsider
> >> precisely what problem you're trying to solve here. This approach can't
> >> tell the difference between legitimate self-regulation of resource
> >> utilization and a real attack. Worse, in the event of a real attack, it
> >> could be used to make it more difficult for the administrator to notice
> >> something much more serious than a forkbomb.
> >>
> >> I suspect that userspace might be a better place to solve this problem.
> >> You could run your monitoring app with elevated or even realtime
> >> priority to ensure it will still function, and you have much more
> >> freedom in making the reporting configurable. You can also look at much
> >> more data than we could ever allow in fork.c, and possibly detect
> >> attacks that this patch would miss if a clever attacker stayed just
> >> below the limit.
> >>
> >> -- Chris
> >>
> > -
> > 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/
> >
>
>
> --
> Simon Arlott
>
