Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by krbdev.mit.edu (8.9.3p2) with ESMTP id PAA22312; Mon, 15 Mar 2004 15:18:54 -0500 (EST)
Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E725715203D; Mon, 15 Mar 2004 15:18:53 -0500 (EST)
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #2198] Not sure this is a bug
Message-Id: <20040315201853.E725715203D@konishi-polis.mit.edu>
Date: Mon, 15 Mar 2004 15:18:53 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc: 
X-RT-Original-Encoding: iso-8859-1
Content-Length: 414


It seems that higher level keytab access routines like
krb5_kt_get_entry are built on the lower level sequential get
operations.  And these entries delete the cursor when they are done.

krb5_get_init_creds_keytab is an even higher level operation.

It doesn't seem unreasonable to me to simply document this
behavior--that higher level op.erations will reuse the same cursor and
thus interrupt a sequential get.