Memory Leak problems with krb5_get_init_creds_password?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
All,
        I am having a problem with the krb5_get_init_creds_password
API call. It looks like it is causing a memory leak, or perhaps I am
not freeing things properly. I am trying to write a pretty simple
plugin to an existing application to do kerberos authentication. While
I got everything working properly and authenticating, during a 12-hour
stress test I noticed a 4.5GB memory leak.

        I have written a simple program that exploits. The simple
program is included at the bottom of the message. I saw messages from
September of 2004 about a similiar problem with this function call,
but I never saw any resolution to this problem. I have observed this
problem using versions 5-1.4.1 (32-bit), 5-1.4.1 (64-bit), and 5-1.4.2
(64-bit) all compiled on Solaris 9 with the Sun Forte compiler (note
that I have not yet compiled/tested this on a 32-bit version of
5-1.4.2, but at this point I don't think that matters).

        So does anyone have any ideas? Am I calling something
incorrectly, or not freeing memory when I should be?

--example program--

#include <stdio.h>
#include <string.h>
#include <krb5.h>

#define PRINC "[hidden email]"
#define PASS "password"

int
main(int argc, char **argv) {

  int            r = 0;
  krb5_context   krb_context = 0;      /* Kerberos context      */
  krb5_principal krb_princ = 0;        /* Kerberos principal    */
  krb5_creds     krb_creds;            /* Kerberos credentials  */

  while (1) {
    memset(&krb_creds, 0, sizeof(krb_creds));
    if ((r = krb5_init_context(&krb_context)) != 0) {
      printf("Could not init krb_contexti: %s\n", error_message(r));
      goto cleanup;
    }
    if ((r = krb5_parse_name(krb_context, PRINC, &krb_princ)) != 0) {
      printf("Could not build krb_princ: %s\n", error_message(r));
      goto cleanup;
    }
    if ((r = krb5_get_init_creds_password(krb_context, &krb_creds,
                                          krb_princ, PASS, NULL, 0, 0,
                                          NULL, 0)) != 0) {
      printf("Kerb auth failed: %s\n", error_message(r));
      goto cleanup;
    }
   
    printf("Auth successful!\n");
    goto cleanup;
   
  cleanup:
    krb5_free_creds(krb_context, &krb_creds);
    if (krb_princ) krb5_free_principal(krb_context, krb_princ);
    if (krb_context) krb5_free_context(krb_context);
  }
}

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (192 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
On Fri, Aug 12, 2005 at 05:44:21PM -0700, Chet Burgess wrote:
> All,
> I am having a problem with the krb5_get_init_creds_password
> API call. It looks like it is causing a memory leak, or perhaps I am
> not freeing things properly. I am trying to write a pretty simple
> plugin to an existing application to do kerberos authentication. While
> I got everything working properly and authenticating, during a 12-hour
> stress test I noticed a 4.5GB memory leak.

        For those curious, the problem is/was the fact that solaris
resolver does not have a call to free the memory allocated by
res_ninit(). Since the kerberos code calls this to search DNS for TXT
and SRV records in attempt to find the REALM for a server and the
KDC(s) for a REALM it needs to use the resolver and this was causing
the leak. The work around I found is by placing the REALM and KDC(s)
in the krb5.conf file and also adding "dns_fallback = false" to the
[libdefaults] section. The "dns_fallback" options tells the libraries
to use only the config file and to never try DNS when trying to find a
REALM and KDC(s). It is important to note that even if you have the
REALM and KDC(s) listed in the file properly the library will still
try DNS first, so you MUST add "dns_fallback = false" to turn off the
resolver calls.

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Jeffrey Altman-3
Chet Burgess wrote:

> It is important to note that even if you have the
> REALM and KDC(s) listed in the file properly the library will still
> try DNS first, so you MUST add "dns_fallback = false" to turn off the
> resolver calls.

I am fairly sure that DNS is not used in preference to the configuration
data in the krb5.conf file.   However, the library probably calls the
resolver library init routine prior to making a request.

Are you suggesting that calling res_init() repeatedly from the same
thread results in a memory leak?

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
On Wed, Aug 17, 2005 at 12:07:40PM +0000, Jeffrey Altman wrote:

> Chet Burgess wrote:
>
> > It is important to note that even if you have the
> > REALM and KDC(s) listed in the file properly the library will still
> > try DNS first, so you MUST add "dns_fallback = false" to turn off the
> > resolver calls.
>
> I am fairly sure that DNS is not used in preference to the configuration
> data in the krb5.conf file.   However, the library probably calls the
> resolver library init routine prior to making a request.

        The res_ninit() call and the subsequent calls for the DNS
records are made in the krb5int_dns_init function found at
src/lib/krb5/os. The res_ninit() call is made for every lookup. As for
the DNS vs. config file variable, I had a proper krb5.conf file that
listed the REALM and the KDCs, untill I added "dns_fallback = false"
to the config file it would always try DNS then look at the config
file.

> Are you suggesting that calling res_init() repeatedly from the same
> thread results in a memory leak?

        Suggesting? I guess I was not clear, calling res_ninit() more
than once will result in a memory leak on Solaris (and on Linux,
though I have not tested this).
       
        Neither Solaris (or Linux) make available a function to free
the memory allocated to a resolver state by res_ninit(). Other flavors
of Unix have a function called res_ndestroy() for just this sort of
thing. In fact Solaris has this function but it is marked as local in
the library so you cannot link against it.

cfb@sandman:> nm /usr/lib/libresolv.so | grep res_ndestroy
[200] | 194936|  60|FUNC |LOCL |0  |9  |res_ndestroy

        The kerberos developers in fact seem to know/understand this
as they have a report of this problem on the krb5-bugs mailing list
(http://mailman.mit.edu/pipermail/krb5-bugs/2005-January/003549.html).

        Below is a simple example program that exploits this problem.

#include <stdio.h>
#include <string.h>
#include <resolv.h>

int
main(int argc, char **argv) {

    struct __res_state statbuf;
    int ret = 0;

    while (1) {
      ret = res_ninit(&statbuf);
      if (ret != 0) printf("Init error!\n");
      res_nclose(&statbuf);
      printf("Done!\n");
    }
}

Compile with something like (this would be for a 64-bit version):
cc -Iinclude -D_REENTRANT -KPIC -xarch=v9 -DUSE_64 -g -c -o
resolvtest.o resolvtest.c

cc -o resolvtest -Iinclude -D_REENTRANT -KPIC
-xarch=v9 -DUSE_64 -g -lresolv -lsocket -lnsl resolvtest.o

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Donn Cave
In article <[hidden email]>, [hidden email] (Chet Burgess)
wrote:
[ ... re memory leak caused by DNS KDC lookup ... ]
> The res_ninit() call and the subsequent calls for the DNS
> records are made in the krb5int_dns_init function found at
> src/lib/krb5/os. The res_ninit() call is made for every lookup. As for
> the DNS vs. config file variable, I had a proper krb5.conf file that
> listed the REALM and the KDCs, untill I added "dns_fallback = false"
> to the config file it would always try DNS then look at the config
> file.

That's weird, but there are some potential surprises.  For an
example I ran into myself, if your initial request fails, it
will be retried to the configured "master_kdc".  Of course if that
isn't in krb5.conf it will go to DNS ("_kerberos-master._udp".)

"master_kdc" is fairly recent and likely not configured at a
lot of sites where the krb5.conf goes back a ways (or maybe
where there is no master KDC, though such sites may as well
configure a value anyway.)

   Donn Cave, [hidden email]
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
On Wed, Aug 17, 2005 at 11:51:08AM -0700, Donn Cave wrote:
> That's weird, but there are some potential surprises.  For an
> example I ran into myself, if your initial request fails, it
> will be retried to the configured "master_kdc".  Of course if that
> isn't in krb5.conf it will go to DNS ("_kerberos-master._udp".)
>
> "master_kdc" is fairly recent and likely not configured at a
> lot of sites where the krb5.conf goes back a ways (or maybe
> where there is no master KDC, though such sites may as well
> configure a value anyway.)

        Interesting. We do not in fact have a "master_kdc" specified
in our config files as they date back almost 7 years at this point. I
will have to add that to our configs.

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (192 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Tom Yu
In reply to this post by Chet Burgess
res_ninit() wasn't the only source of the leak.  Ticket #3147 covers a
different leak, which resulted from not freeing some profile strings.

---Tom
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
On Wed, Aug 17, 2005 at 03:19:52PM -0400, Tom Yu wrote:
> res_ninit() wasn't the only source of the leak.  Ticket #3147 covers a
> different leak, which resulted from not freeing some profile strings.
       
        Yeah I saw that in the reference. I was using that an evidence
that the developers are aware of the issue and have done everything
they can to avoid the leak by calling res_ndestroy on the platforms
that provide it.

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (192 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess
Memory leaks are concerning to my project.  It'd be more of
a concern if we hadn't decided to support Heimdal too.

How many known memory leaks still exist in MIT Kerberos?

Also, this is not meant to be offensive, but if there are
known memory leaks, why haven't they at least been minimized?
I mean there are often easy workarounds.  If Chet read the
source code properly, res_ninit() is being called before every
DNS lookup, but given the leaks, it probably should be called
from krb5_init_context().  (However, Chet's program doesn't
actually test that this isn't already being done, since the
krb5_init_context call is made inside of the while loop.)
The leak also could be minimized by checking timestamps and
only calling res_ninit only if the DNS config files changed.

Anyways, we are developing a software package built on top of
MIT Kerberos to perform Active Directory authentication from
UNIX throughout our entire company (over 100,000 employees).
But we can't do this until all leaks are at least minimized.
I'd do it myself, but my company tries to avoid certain
customizations.  Basically I can't modify/recompile the MIT
source which BTW has created alot more work for me.  I could
possibly submit a patch though.

Thanks.
Brian Joh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess
I looked at the Heimdal source, and apparently it has this
issue too.  Didn't run any tests to verify this though.

I looked at BIND, and indeed res_ndestroy() is defined in
the resolv.h header file, but not exported.  However, while
perusing the source, I noticed if res_ninit() is called
more than once on the same res_state structure it will call
res_ndestroy() to free up the old memory.  Basically,
res_ninit() sets the RES_INIT bit.  Before doing anything,
it also checks that bit, and, if set, calls res_ndestroy().
Res_ndestroy()then unsets that bit.

Knowing this, minimizing the memory leak should be really
simple.  The res_state structure needs to be moved inside
the krb5_context.  The call to res_ninit() doesn't need to
move, but it needs to use the res_state stored in the
krb5_context.  (Basically, it needs to use the same
res_state structure each time.)

Note a memory leak should still exist if you constantly
create krb5_contexts as Chet's program does.  However,
Chet's program is inefficient, and you should really never
need more than one krb5_context per thread/program.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Tom Yu
In reply to this post by brian.joh
>>>>> "brian" == brian joh <[hidden email]> writes:

brian> How many known memory leaks still exist in MIT Kerberos?

You can look at our bug database at http://krbdev.mit.edu/rt/ for the
current status of reported bugs.  I don't think there are many at this
point.  We try to fix any leaks we discover or which are reported.  If
you know of any memory leaks which we have not fixed, please file a
bug report.  We can't fix leaks we don't know about.

brian> Also, this is not meant to be offensive, but if there are
brian> known memory leaks, why haven't they at least been minimized?
brian> I mean there are often easy workarounds.

With our current resources, we cannot possibly keep track of all the
operating system bugs which may introduce memory leaks.  Working
around every OS bug which causes a leak could rapidly cause
maintainability problems for us.

brian> If Chet read the source code properly, res_ninit() is being
brian> called before every DNS lookup, but given the leaks, it
brian> probably should be called from krb5_init_context().

The leak in res_ninit() results because the OS vendor did not expose
the corresponding res_ndestroy() API which is needed to free resources
allocated by res_ninit().  We consider this to be an OS bug.  While we
can work around OS bugs, we prefer that the OS vendor actually fix the
bug.

brian> (However, Chet's program doesn't actually test that this isn't
brian> already being done, since the krb5_init_context call is made
brian> inside of the while loop.)  The leak also could be minimized by
brian> checking timestamps and only calling res_ninit only if the DNS
brian> config files changed.

Another possible approach is to use res_search() rather than
res_nsearch() on platforms which lack res_ndestroy(), under the
assumption that the OS vendor has made the "static" resolver
interfaces thread-safe.  We could also cache the resolver state on a
per-thread basis, but that requires more work.

brian> But we can't do this until all leaks are at least minimized.
brian> I'd do it myself, but my company tries to avoid certain
brian> customizations.  Basically I can't modify/recompile the MIT
brian> source which BTW has created alot more work for me.  I could
brian> possibly submit a patch though.

If you find memory leaks which haven't been fixed yet, please file
bug reports on them so that we can be aware of them.  Good quality
patches are welcome.

---Tom
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Chet Burgess
In reply to this post by brian.joh
On Thu, Aug 18, 2005 at 01:22:29PM -0700, [hidden email] wrote:
> Note a memory leak should still exist if you constantly
> create krb5_contexts as Chet's program does.  However,
> Chet's program is inefficient, and you should really never
> need more than one krb5_context per thread/program.

        At no point was there any assumption that the program I
provided was efficient. It was a proof of concept program to show how
to exploit the memory leak. I agree that placing the res_state
variable into the krb5_context is a good solution, and that creating
multiple contexts in the same thread is unneccessary.

--
Chet Burgess

Manager, Enterprise Collaboration Services
Information Services Division
University of Southern California
[hidden email]
213-740-5160

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (192 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess
Tom, OK.  If you feel this solution is acceptable, I'll write some
code to minimize this leak as describe in my second message.  (Use
exactly one res_state structure for each krb5_context, but still
call res_ninit() right before the lookup.  Res_ninit() will then
deallocate the res_state before reallocating it.)  It should be
really simple (less than a dozen lines of code), but I won't spend
my time doing it, if you guys don't feel it's the right direction.

Probably not til next week, though.  I am officially on vacation
as of right now.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess
>At no point was there any assumption that the program I
>provided was efficient. It was a proof of concept program to show how
>to exploit the memory leak. I agree that placing the res_state
>variable into the krb5_context is a good solution, and that creating
>multiple contexts in the same thread is unneccessary.

I know you weren't trying to write any production code or
anything.  I was just pointing out, that if the memory leak
is moved to krb5_init_context(), then the problem is solved
for realistic cases.  And I was just trying to say it wouldn't
fix the problem in your test program and that your leak
test would still leak.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Kenneth G Raeburn
On Aug 18, 2005, at 17:49, [hidden email] wrote:
> I know you weren't trying to write any production code or
> anything.  I was just pointing out, that if the memory leak
> is moved to krb5_init_context(), then the problem is solved
> for realistic cases.  And I was just trying to say it wouldn't
> fix the problem in your test program and that your leak
> test would still leak.

We've run into other cases where a krb5_context is needed but other  
APIs make it difficult for one to be made available.  So there's code  
out there that allocates many short-lived krb5_context structures,  
often without using them for actual network stuff.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess

Ken Raeburn wrote:

> We've run into other cases where a krb5_context is needed but other
> APIs make it difficult for one to be made available.  So there's code
> out there that allocates many short-lived krb5_context structures,
> often without using them for actual network stuff.

OK, thinking back, I can see how it might be difficult to
keep a krb5_context around in certain situations.

However, although I said the change I proposed would move
the "memory leak to krb5_init_context", this wasn't totally
accurate.  Basically, the memory leak would still occur
from the same place in the code (in the DNS SRV lookup code
apparently), but it would occur AT MOST once per
krb5_context.  Res_ninit() still gets called in exactly the
same spot, it just uses a PER krb5_context res_state
structure.  Then, res_ninit() apparently will deallocate
the structure, before initializing it again.

If this change was made, short-lived krb5_context structures
that do DNS SRV lookups (I think this is where res_ninit is
called), would still leak, just not as much.  Short-lived
krb5_context structures that didn't need to do any DNS
stuff wouldn't leak.

Basically, the situation would improve for many important
cases, and there isn't a scenario that I can think of, where
the memory leak would get worse.

Brian

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

hartmans
>>>>> "brian" == brian joh <[hidden email]> writes:

    brian> Ken Raeburn wrote:

    >> We've run into other cases where a krb5_context is needed but
    >> other APIs make it difficult for one to be made available.  So
    >> there's code out there that allocates many short-lived
    >> krb5_context structures, often without using them for actual
    >> network stuff.

    brian> OK, thinking back, I can see how it might be difficult to
    brian> keep a krb5_context around in certain situations.

    brian> However, although I said the change I proposed would move
    brian> the "memory leak to krb5_init_context", this wasn't totally
    brian> accurate.  Basically, the memory leak would still occur
    brian> from the same place in the code (in the DNS SRV lookup code
    brian> apparently), but it would occur AT MOST once per
    brian> krb5_context.  Res_ninit() still gets called in exactly the
    brian> same spot, it just uses a PER krb5_context res_state
    brian> structure.  Then, res_ninit() apparently will deallocate
    brian> the structure, before initializing it again.

I'm not sure we have a desire to keep calling res_ninit multiple
times.

I think once per context might be acceptable actually.

this is my personal opinion though, not a decision on the issue.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

Kenneth G Raeburn
Yes, I think allocating the storage and initializing it at most once  
per context, delayed until the actual resolver usage, is the right  
way to deal with this.  Simply adding a pointer field to the context,  
initialized to NULL, is probably the way to start....

Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh
In reply to this post by Chet Burgess
Yeah, I wasn't sure what the standard practice is, and whether
it was necessary to keep calling res_ninit() multiple times per
context.  I suggested that route because it is more conservative.
It keeps all the functionality the same, while reducing the leak.  

Res_ninit() is supposed to read the DNS config files, and it
was my *impression* that most applications want to always
have the latest DNS config.   For example, if you change
your name servers in /etc/resolv.conf, my *impression* was
most running applications will "see" the new name servers
with a restart.   MIT and Heimdal currently do this.

Brian

-------------- Original message --------------

> Yes, I think allocating the storage and initializing it at most once
> per context, delayed until the actual resolver usage, is the right
> way to deal with this. Simply adding a pointer field to the context,
> initialized to NULL, is probably the way to start....
>
> Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Memory Leak problems with krb5_get_init_creds_password?

brian.joh

Frank Cusack wrote:

> On Tue, 23 Aug 2005 14:36:02 +0000 [hidden email] wrote:
> > Yeah, I wasn't sure what the standard practice is, and whether
> > it was necessary to keep calling res_ninit() multiple times per
> > context.  I suggested that route because it is more conservative.
> > It keeps all the functionality the same, while reducing the leak.
> >
> > Res_ninit() is supposed to read the DNS config files, and it
> > was my *impression* that most applications want to always
> > have the latest DNS config.   For example, if you change
> > your name servers in /etc/resolv.conf, my *impression* was
> > most running applications will "see" the new name servers
> > with a restart.   MIT and Heimdal currently do this.
>
> That's not typical.  Most applications call res_ninit() only once.
>
> -frank

Ok.  It's not tough to call res_ninit() before just the
*first* DNS SRV lookup.  It's a tiny bit more work, but not
difficult.  Could do it by declaring a res_state pointer in
the krb5_context, and just checking the pointer.
Alternatively, might be able to store the actual structure
(not the pointer) inside the krb5_context and check the
res_state.options for the RES_INIT flag.

I could implement this, but not til next week.  Got alot on
my plate at work.  

-Brian

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos