On Aug 29, 2007, at 09:49:01, Chris Snook wrote:
Like this there are many cases..(actually these cases has already
been discussed On LKML 2 months before in my thread named "fork
bombing
attack"). in all these cases this printk helps adminstrator a lot.
What exactly does this patch help th
Anand Jahagirdar wrote:
Hi
consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
If root is dumb en
Hi
consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
(I have already tried this attack). in that ca
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
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
On 23/08/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Chris Snook <[EMAIL PROTECTED]> writes:
>
> > Wrapping a single printk that's unrelated to debugging in an #ifdef
> > CONFIG_* or a sysctl strikes me as abuse of those configuration
> > facilities.
>
> Abuse, probably not (if a thing is req
Chris Snook <[EMAIL PROTECTED]> writes:
> Wrapping a single printk that's unrelated to debugging in an #ifdef
> CONFIG_* or a sysctl strikes me as abuse of those configuration
> facilities.
Abuse, probably not (if a thing is required on one system and must
not be on another, it has to be configur
Krzysztof Halasa wrote:
Hi,
"Anand Jahagirdar" <[EMAIL PROTECTED]> 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, s
Hi,
"Anand Jahagirdar" <[EMAIL PROTECTED]> 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 CON
Hi
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?
anand
On 8/20/07, Chris Snook <[EMAIL PROTECTED]> wrote:
> Anand Jahagirdar wrote:
> > H
Anand Jahagirdar wrote:
Hi
As Per the Previous Discussion of my Patch,I think insted of using
KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
thats why i used KERN_WARNING.it will warn administrator and its
administrator responsibility to take whatever action he want to tak
(please don't top-post)
On 20/08/07, Anand Jahagirdar <[EMAIL PROTECTED]> wrote:
> Hi
> I think Its not worth to make it configurable just for one printk
> statement. am i missing something?
>
I think you are missing the fact that there are lots of situations
where users may hit the configured
Hi
I think Its not worth to make it configurable just for one printk
statement. am i missing something?
anand
On 8/16/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> "Anand Jahagirdar" <[EMAIL PROTECTED]> writes:
>
> > +++ linux-2.6.17/kernel/fork.c
> > +/*
> > + * following c
Hi
As Per the Previous Discussion of my Patch,I think insted of using
KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
thats why i used KERN_WARNING.it will warn administrator and its
administrator responsibility to take whatever action he want to take.
anand
On 8/17/07, Chr
I agree that (1) one risks overdoing comments and (2) one should minimize
comments inside a function body.
But I read your earlier statement:
Please do not add comments inside functions.
as simply requesting no comments inside function bodies, without
exception. That seems to me to be too str
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Jackson wrote:
> Petr wrote:
>> Please do not add comments inside functions.
>
> I find this advice a bit odd. I am not aware of
> any prohibition of comments inside functions.
>
> As with comments outside functions, they should
> serve a worth
Petr wrote:
> Please do not add comments inside functions.
I find this advice a bit odd. I am not aware of
any prohibition of comments inside functions.
As with comments outside functions, they should
serve a worthwhile purpose, of course. One might
debate whether this particular comment added
Anand Jahagirdar wrote:
Hello All
I have searched for Maintainers List to get the correct
Maintainer for my patch. But i am not getting exact maintainer to
which i should forward my patch. Will any body please tell me,to which
maintainer i should forward my patch for its inclusion?
Su
On Aug 16 2007 13:19, Krzysztof Halasa wrote:
>
>At least make that configurable - on some systems users are allowed
>50 processes or so and I'm sure admins don't really want to know
>which particular users are currently close to limits.
>
>I don't really find the above useful. Perhaps we should w
"Anand Jahagirdar" <[EMAIL PROTECTED]> writes:
> +++ linux-2.6.17/kernel/fork.c
> +/*
> + * following code does not allow Non Root User to cross its process
> + * limit and it alerts administrator about user Nearing the process
> limit.
> + */
> +
>
On Thu, 2007-08-16 at 11:54 +0530, Anand Jahagirdar wrote:
> Hello All
>I have searched for Maintainers List to get the correct
> Maintainer for my patch. But i am not getting exact maintainer to
> which i should forward my patch. Will any body please tell me,to which
> maintainer i sho
Hello All
I have searched for Maintainers List to get the correct
Maintainer for my patch. But i am not getting exact maintainer to
which i should forward my patch. Will any body please tell me,to which
maintainer i should forward my patch for its inclusion?
Summery of the Patch:
This
22 matches
Mail list logo
