[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: minimum buf_size doesn't fit me anymore
From: |
Chip Seraphine |
Subject: |
Re: minimum buf_size doesn't fit me anymore |
Date: |
Wed, 14 Apr 2004 08:46:03 -0500 |
User-agent: |
KMail/1.5.4 |
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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>