Kerberos Digest, Vol 28, Issue 32

[Lamar.Saxon@americredit.com]

Tried the suggestions below ( changes to dnsglue.c )

First option compiled; but gave the same errors locating KDC.

Second option would not compile.  Lots of errors.

Thanks,
Lamar

------------------------------

Date: Tue, 26 Apr 2005 16:36:26 -0400
From: Ken Raeburn <raeburn at MIT.EDU>
To: Milton Turley <mturley at lanl.gov>
Cc: kerberos at mit.edu
Subject: Re: KRB5 1.4 vs. KRB5 1.3.6 on AIX 5.2 (fwd)
Message-ID: <7768dc62668092bd09f0fb17051b44bc at mit.edu>
In-Reply-To: <6.0.1.1.2.20050426111426.033677d0 at cic-mail.lanl.gov>
References: <6.0.1.1.2.20050426111426.033677d0 at cic-mail.lanl.gov>
Content-Type: text/plain; charset=US-ASCII; format=flowed
MIME-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 9

On Apr 26, 2005, at 13:40, Milton Turley wrote:
> I have done some research on this problem.  The host resolve code does

> not complete successfully.  I have traced the error to the routine at
> /kerberos/mit/krb5-1.4/src/lib/krb5/os/dnsglue.c.   In the routine a
> call is made to res_ninit to provide dns information for the kdc. 
> res_ninit updates the structure at statbuf but overlays memory 72
> bytes past the structure boundary.

If we change statbuf to something like:
   struct { struct __res_state s; char pad[72]; } statbuf;
or perhaps:
   struct { struct __res_state s; char pad[72]; } statbuf1;
   #define statbuf (statbuf1.s)
does it work then?

Do the AIX 5.2 headers declare res_ninit and indicate what type should
be used for the first argument?

> I have opened a problem with IBM on res_ninit.  The problem is not yet

> resolved but IBM suggested using a malloc for the structure instead of

> static storage.  I am trying to get IBM to correct the error in
> res_ninit.  No resoultion yet.

Well, technically, we're using automatic storage, not static, but it
seems to me that the problem is not knowing the size and/or type to
allocate, not stack vs heap allocation.  (Though heap allocation would
change the failure mode caused by an overrun, it wouldn't by itself get
rid of the overrun.)

Ken

------------------------------

_______________________________________________
Kerberos mailing list
Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


End of Kerberos Digest, Vol 28, Issue 32
****************************************


Privileged and Confidential.  This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information.  If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail.  You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.