I really do hope that's a typo' :-) ".diff" is 5 characters not 4.
update = (char *) sgMalloc(strlen(file) + 6);
strcpy(update,file);
strcat(update,".diff");
if(stat(update,&st) == 0){
sgLogError("update dbfile %s",dbfile);
sgDbLoadTextFile(Db,update,1);
This (fixed version) is really a simple piece of code, the goal is
concatenate a couple of strings. The goal is clear, we want to add ".diff"
onto the end of the filename.
Let's say the filename is FRED, to store that as a string we need 5 bytes,
that's one for each letter and the null ("/0") terminator.
So, the first line is allocating the space we need, the space is simple,
it's what we use now plus what we need for the addition. We know the answer
is 10 so it's 5 more than the length of the current string, easy stuff. The
problem is that strlen() returns the length of a string not including the
null terminator, in this case the would be 4. So, 4 + 5 is 9 (usually) which
ain't going to work, "FRED.DIFF" is 9 characters and it has to null
terminated, the answer should have been 10.
Then along comes the strcat which glues the two strings together. It does
this by removing the null from the end of "FRED/0", adding the ".DIFF" then
terminating with a null. This last null is off into someplace in memory we
did not reserve. The problems then only occur if that area of memory got
used already which is why peoples results will vary, if nothing used the
memory then everything's cool. Funnily enough I get a CTRL-A each time on
RedHat but that's random.
Ian
-----Original Message-----
From: Rick Matthews [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 04, 2002 16:24
To: Ian Spare; [EMAIL PROTECTED]
Subject: RE: ident
Ian Spare wrote:
>
> Unless you don't think that 5+1 is 6 then we can probably assume
> it's true :-)
I'm not a C programmer, but I do have a fair amount of programming and
scripting experience. If the error is in fact, as straightforward as:
length of file name + 4 ('.diff') + 1 (end marker), then I have
trouble understanding:
- How it has been in production for 3 years
- How it made it through at least 6 revision cycles
- How it has not been spotted by the thousands of eyeballs that have
seen it
- Why it only affects a literal handful of people
The older, inferior languages that I have used would complain if you
specifically asked for a 1 gallon bucket and then tried to put 2
gallons of water in it. Or if they didn't complain, they would put
1 gallon in your bucket and throw away the other gallon. I guess
it takes a new and improved language to ignore the defined structure
and blindly corrupt surrounding memory.
I'm not saying that you are wrong, I'm just don't know if you are
right. :-)
Rick
> The reason that this has become noticeable, IMHO, was
> just some subtle alteration in glibc on Linux. It works fine on some
> other platforms I tried as well (the error is still there obviously
> it just doesn't hurt). For that matter I'm not entirely sure that
> there's not a couple of similar errors.
>
> As for the support issues, there's nothing in the license (as I read
> it) to stop any of us releasing a version 2, or son of Squidguard
> version anytime we like :-)
>
> Ian
>
> -----Original Message-----
> From: Rick Matthews [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 13:36
> To: Ian Spare; [EMAIL PROTECTED]
> Subject: RE: ident
>
>
> Ian Spare wrote:
> >
> > To clarify, I meant the obvious error in the sgMalloc call at
> > line 146 of sgDb.c, i.e. 5 + 1 equals 6 in most cases not 5. Or
> >
> > update = (char *) sgMalloc(strlen(file) + 5);
> >
> > should be
> >
> > update = (char *) sgMalloc(strlen(file) + 6);
> >
>
> If that is true, it has been an "obvious error" in all of these
> releases (it is the same code):
>
> squidGuard-1.1.0.beta1.tar.gz 23-Aug-1999 13:13
> squidGuard-1.1.0.tar.gz 24-Aug-1999 17:12
> squidGuard-1.1.1.tar.gz 27-Jan-2000 15:41
> squidGuard-1.1.2.tar.gz 25-Feb-2000 10:59
> squidGuard-1.1.3.tar.gz 06-Mar-2000 11:16
> squidGuard-1.1.4.tar.gz 04-Apr-2000 10:31
> squidGuard-1.2.0.tar.gz 18-Dec-2001 15:34
>
> It is truly a shame that the author no longer takes an interest in
> squidGuard.
>
> Rick
>
>
>
>
> > -----Original Message-----
> > From: Rick Matthews [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, October 03, 2002 06:27
> > To: Ian Spare; [EMAIL PROTECTED]
> > Subject: RE: ident
> >
> >
> > Ian Spare wrote:
> > >
> > > I wouldn't worry about upgrading SquidGuard and DB, it really ought
> > > not to take more than a few minutes really, it's a bit hard to see
> > > what the song and dance is all about in fact.
> >
> > Some of the singing and dancing relates to the fact that the
> > installation instructions that accompany the current squidGuard
> > download are incorrect. Following the installation instructions will
> > reward you with a squidGuard installation that does not work as
> > advertised. That may not be an issue for you, but that's a
> > show-stopper for many people.
> >
> > > The only genuine problem is a bug in some versions of
> > > SquidGuard[sgDb.c] which was discussed in this mail list but as far
> > > I can see hasn't made it into the distribution.
> >
> > I wasn't aware that any discussions here had achieved the status of
> > "genuine problem". In fact, I haven't seen any messages from the
> > author here in almost 2 years. Can you give any more details about
> > this problem?
> >
> > You mention that the problem is in "some versions" of squidGuard. As
> > far as I know, there is one current version of squidGuard and several
> > old versions of squidGuard. Is the problem in the current version or
> > an old version?
> >
> > Thanks,
> >
> > Rick
> >
>
