Re: minimum buf_size doesn't fit me anymore

[Chip Seraphine]

Upgraded to 2.1.5, but the enlarged ALLCLASSBUFFER is still broken because the 
BufferOverflow() function doesn't know that ALLCLASSBUFFER is allowed to be 
bigger than a regular buffer, so it fails when called from ExpandVarstring. 

ExpandVarstring tests the buffer twice with BufferOverflow, first at line 354 
then again at 627.  The second one can be replaced with a 
"strlen(ALLCALSSBUFFER) > ALLCLASSBUFFERSIZE" or similar (assuming you 
#define ALLCLASSBUFFERSIZE to the appropriate value), but the first one is 
hit by everything that uses ExpandVarstring, and hence is hard to dodge.

I'm guessing the way to fix this is to either (a) expand the classlist via 
something other than ExpandVarstring or (b) only test for buffer overflow 
after we know the sort of buffer we are dealing with instead of at the top of 
the function.   The first option sounds tedious and the second one sounds 
unsafe, at least from my point of view (as someone not overly familiar with 
the code).

I guess the workaround is to jackup bufsize, but that increases a lot of 
buffers that don't really need increasing.  *sigh*

On Saturday 10 April 2004 11:32, Mark.Burgess@iu.hio.no wrote:
> 
> Better to add this only to ALLCLASSBUFFER[4*bufsize]. Will be in 2.1.5
> 
> M
> 
> 
> On  8 Apr, Chip Seraphine wrote:
> > A-whups, got the bufsizes mixed up.  Should have been bufsize.
> > 
> > I'm using the RPM stuff to manage my entire packagelist, which at 1000+ 
RPMs 
> > results in a lot of classes being set and "Buffer overflow constructing 
> > string. Increase bufsize macro." messages when passing it to a 
shellcommand.
> > 
> > On Thursday 08 April 2004 16:49, Mark.Burgess@iu.hio.no wrote:
> >> 
> >> Do you mean buf_size (file block size) or bufsize (internal array size)?
> >> What does this have to do with rpms?
> >> 
> >> M
> >> 
> >> On  8 Apr, Chip Seraphine wrote:
> >> > 
> >> > I've been fooling around in v 2.1.3 with the new RPM stuff and so far 
it 
> >> > seems quite nice.    The one issue is that I had to significantly jack 
up 
> >> > my minimum buf_size (client.c line 543) from 2048 to 8192; this seems 
> >> > somewhat unavoidable if you are using the packages: toys, unless you 
are 
> >> > only using it to add the occasional odd RPM instead of the whole lot.
> >> > 
> >> > Cfengine does a lot more than it used to, and humongeous class strings 
are 
> >> > probably becoming more common. Perhaps we could up it some to reflect 
> > this? 
> >> > 
> >> > Here's the tiny change I made in 2.1.3 to allow me to do 
> >> > CFLAGS="-DMIN_CLIENT_BUF_SIZE=8192" on the ./configure line.   If 
others 
> >> > are having this issue it may prove convenient.
> >> > 
> >> > 
> >> > --- client.c    2004-04-08 11:15:53.000000000 -0500
> >> > +++ client.c.orig       2004-04-08 11:12:40.000000000 -0500
> >> > @@ -540,7 +540,7 @@
> >> > 
> >> >  if (buf_size < 2048)
> >> >     {
> >> > -   buf_size = MIN_CLIENT_BUF_SIZE;
> >> > +   buf_size = 2048;
> >> >     }
> >> > 
> >> >  if (ip->encrypt == 'y')
> >> > 
> >> > 
> >> > --- cf.defs.h   2004-04-08 11:15:20.000000000 -0500
> >> > +++ cf.defs.h.orig      2004-04-08 11:12:46.000000000 -0500
> >> > @@ -345,10 +345,6 @@
> >> > 
> >> >  #define CFLOGSIZE 1048576                  /* Size of lock-log before 
> >> > rotation */
> >> > 
> >> > -#ifndef MIN_CLIENT_BUF_SIZE
> >> > -#define MIN_CLIENT_BUF_SIZE 2048
> >> > -#endif
> >> > -
> >> >  /* Output control defines */
> >> > 
> >> >  #define Verbose if (VERBOSE || DEBUG || D2) printf
> >> > 
> >> > 
> >> > <FEATURE_REQUEST type="cleverly disguised as speculation">
> >> > This might not be as necessary if there were some more granular means 
of 
> >> > assembling ${allclasses}-like strings; like an 
> >> > AddClassnameToStringButOnlyIfItIsActuallyDefined(class1 class2 classN) 
> > sort 
> >> > of thing that jammed its argument classes into ${someclasses} if they 
were 
> >> > true, so that I could then call my  scripts/modules with ${someclasses} 
> > (or 
> >> > a copy of same) as an argument instead of ${allclasses}.
> >> > 
> >> > Or do most people not routinely use cfengine classes to turn on/off 
large 
> >> > numbers of options to scripts and modules?
> >> > </FEATURE_REQUEST>
> >> > 
> >> > 
> >> > 
> >> > _______________________________________________
> >> > Help-cfengine mailing list
> >> > Help-cfengine@gnu.org
> >> > http://mail.gnu.org/mailman/listinfo/help-cfengine
> >> 
> >> 
> >> 
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
> >> Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> 
> 
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
> Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>