help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: minimum buf_size doesn't fit me anymore


From: Mark . Burgess
Subject: Re: minimum buf_size doesn't fit me anymore
Date: Wed, 14 Apr 2004 15:52:15 +0200 (MEST)

It seems that ExpandVarstring is not used in connection with ALLCLASSBUFFER,
but rather at line 1842 of cfagent.c there is a limit of bufsize.
Can that be the answer?

M

On 14 Apr, Chip Seraphine wrote:
> 
> 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
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]