On Fri, 24 Mar 2000, Dungeonkeeper wrote:

> 
> 
> Hi there,
> 
> First of all: I want to apologise for my poor english.
> 
> Today me and a few friends of mine discussed the shells' (well, shell is
> actualy one of: sh/bash/csh/tcsh... not tested for ksh) command line expansion
> routines, mainly because of a problem discovered by one of my friends. I'm not
> sure if this is something new... So, let me explain what he found. It seems
> that the shell wants to allocate enough memory to hold the entire command line
> when expanding all of the arguments and we can force it to allocate hudge
> ammount of memory with a tricky command like this:
> 
> carnivoro# /bin/csh -c `cat /dev/urandom`
> 



> (I use tcsh here (the carnivoro# prompt), but the same thing happens when
> testing with sh/bash/tcsh) In this situation, the shell tries to allocate enough
> memory to hold what it
> reads from /dev/urandom, because it must be passed as a command line argument
> to /bin/csh ( actually, any command will be ok ). So, the shell eats more and
> more memory (on my machine (3.4-STABLE) - 251 MB) before the kernel decided to
> take some action (like killing some processes... started by other users?
> system services? or... in my case... crash :). My friend said that he sent a
> mail to bugtraq describing this problem. Those who are interested can read it.
> 

I tried this too: /bin/csh -c `cat /dev/urandom`
My shell grew to around 260MB, then "bash: xrealloc: cannot reallocate
134217728 bytes (0 bytes allocated)"
Then it exited to the logon prompt.
The rest of the system didn't notice. Happened both as root and normal.

I tried this with ridiculously 8GB swap (just for fun...).
With 128MB swap, the system complained when the swap got full, but then
only killed the shell, returning me to the logonprompt on that window.
No other problems either.

Leif

> I believe that the shells have a maximum command lenght, so... I'm trying now
> to make the shell use the same command lenght when expanding such commands. I
> think this is the best way to avoid this problem. Any ideas?
> 
> Best regards: zethix 
> 
> 
> What is worth doing is worth the trouble of asking somebody to do.
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to