[2177] in Kerberos_V5_Development
Comments on Krb5-nt-alpha1 - DLL / Application Problems
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Sat Jan 25 15:37:39 1997
Date: Sat, 25 Jan 1997 14:08:08 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
Reply-To: deengert@anl.gov
To: krbdev@MIT.EDU
Cc: deengert@anl.gov
I have sucessfully compiled the krb5-nt-alpha1.zip release on Windows 95
using the MS C++ 4.2. I have also converted my 16 bit rlogin program
which is written in Borland C++ to a 32 bit version.
This note describes two problems with suggested fixes with using DLLs.
These are basicly the same problems I have reported before with the
16 bit Windows versions from the Betas and the krb5-1.0.
The first problem deals with the way the entry points into the crypto
routines are handled. The rlogin application needs to call
the krb5_use_encrypt, krb5_decrypt, krb5_use_enctype and
krb5_process_key macros. These macros load entry points of
of routines which are in the DLL. These must be export for the
application to have access.
As an enhancement for future applications, I would like to suggest the
these macros be converteted to routines which are then exported. This
then means that none of the crypto routines needs to be exported, which
will help with future releases as new routines are added, they will
become accessable to older applications as well.
It appears that the release has dealt with this to some extent
in the krb5_32.def file were you have a comment:
;Temporary exports (DO NOT USE)
Followed by some of the crypto routines.
The second problem is similier. The fwd_tgt.c routines allocates
a buffer from the heap of the DLL, for the forwarded ticket, and
returns it to the caller, which may be the application. (In my
case it is a modified version of kcmd.c The wintel\auth.c also
has this problem, and it is fixed with a "#if 0 /* XXX */")
The application can not free this memory when it is done.
This two can be solved by having a routine in the DLL to free
memory obtained by the DLL.
There may be other situations as well, where this can cause a problem.
I only know about the fwd_tgt.c problem.
I have added to win_glue.c these routines, and added definitions
in krb5.hin, and exports in krb5_32.def:
krb5_32.def:
!> ;Added by DEE
!> krb5_dll_malloc
!> krb5_dll_xfree
!> krb5_dll_use_enctype
!> krb5_dll_process_key
!> krb5_dll_encrypt
!> krb5_dll_decrypt
win_glue.c:
!> /* There are needed to get at the encryption routines, which
!> * are accessed via loading the entry point from a table. Since
!> * these routines are in the DLL, and are not exported, and are NEAR
!> * pointers, we need to get to the DLL, then we can load and call
them.
!> *
!> * The alloc and free routines were also added here, since the DLL
!> * has its own heap. Tring to free storage in the application which
!> * is in the DLL's heap, causes problems. These allow the
application
!> * to get storage in the DLL's heap, and to free it. The kcmd
routine
!> * needs this, and the outbuf from get_for_creds also has the
!> * problem since the application needs to free this area.
!> *
!> * Doug Engert ANL 1/96
!> * Doug Engert ANL for WIN32 1/18/97
!> */
!> KRB5_DLLIMP krb5_error_code KRB5_CALLCONV
!> krb5_dll_use_enctype(context, eblock, enctype)
!> krb5_context context;
!> krb5_encrypt_block FAR * eblock;
!> krb5_enctype enctype;
!> {
!> krb5_use_enctype(context, eblock, enctype);
!> return 0;
!> }
!>
!> KRB5_DLLIMP krb5_error_code KRB5_CALLCONV
!> krb5_dll_process_key(context, eblock, keyblock)
!> krb5_context context;
!> krb5_encrypt_block FAR * eblock;
!> krb5_keyblock FAR * keyblock;
!> {
!> return krb5_process_key(context, eblock, keyblock);
!> }
!> KRB5_DLLIMP krb5_error_code KRB5_CALLCONV
!> krb5_dll_encrypt(context, inptr, outptr, size, eblock, ivec)
!> krb5_context context;
!> krb5_pointer inptr;
!> krb5_pointer outptr;
!> krb5_const size;
!> krb5_encrypt_block FAR * eblock;
!> krb5_pointer ivec;
!> {
!> return krb5_encrypt(context, inptr, outptr, size, eblock, ivec);
!> }
!> KRB5_DLLIMP krb5_error_code KRB5_CALLCONV
!> krb5_dll_decrypt(context, inptr, outptr, size, eblock, ivec)
!> krb5_context context;
!> krb5_pointer inptr;
!> krb5_pointer outptr;
!> krb5_const size;
!> krb5_encrypt_block FAR * eblock;
!> krb5_pointer ivec;
!> {
!> return krb5_decrypt(context, inptr, outptr, size, eblock, ivec);
!> }
!>
!> KRB5_DLLIMP void FAR * KRB5_CALLCONV
!> krb5_dll_malloc(size)
!> int size;
!> {
!> return (void FAR *)malloc(size);
!> }
!>
!> KRB5_DLLIMP void KRB5_CALLCONV
!> krb5_dll_xfree(val)
!> void FAR * val;
!> {
!> krb5_xfree(val);
!> }
krb5.hin:
#if (defined(_MSDOS) || defined(_WIN32))
/*
* begin "win_glue.c"
*/
KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_dll_use_enctype
KRB5_PROTOTYPE((krb5_context, krb5_encrypt_block FAR *, krb5_enctype));
KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_dll_process_key
KRB5_PROTOTYPE((krb5_context, krb5_encrypt_block FAR *, krb5_keyblock
FAR *));
KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_dll_encrypt
KRB5_PROTOTYPE((krb5_context, krb5_pointer, krb5_pointer, krb5_const,
krb5_encrypt_block FAR *, krb5_pointer));
KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_dll_decrypt
KRB5_PROTOTYPE((krb5_context, krb5_pointer, krb5_pointer, krb5_const,
krb5_encrypt_block FAR *, krb5_pointer));
KRB5_DLLIMP void FAR * KRB5_CALLCONV krb5_dll_malloc
KRB5_PROTOTYPE((int));
KRB5_DLLIMP void KRB5_CALLCONV krb5_dll_xfree
KRB5_PROTOTYPE((void FAR *));
/*
* end stuff from "win_glue.c"
*/
#endif
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
