Patch: System keytab usage improvements
Rakesh Patel
rapatel at optonline.net
Wed Jun 2 00:52:24 GMT 2004
Dan, thanks for all your efforts. I will test the patch shortly
and there are two others who have been utilizing the patch during
this process and can assist in ensuring extensive testing of the code.
I haven't had a chance to review the code, however the discussions
with Andrew indicate we should be fine.
My only comment would be that I have always seen the key version
number start at 1 instead of 0 for MIT Kerberos v5 (since 1990).
Guenther had originally set the value to 1 in the first version of the
patch. I have not tested with Windows2000 - can anyone confirm the
default key version used by Windows 2000? (I am testing with Windows 2003
which of course supports key version numbers).
Thanks,
Rakesh Patel.
Dan Perry wrote:
>Here is a link to an updated patch that addresses the points Andrew brought
>up below.
>
>http://www.pppl.gov/~dperry/patches/keytab.v6.samba-3.0.5pre1.diff
>
>As far as the originator(s) of the code, the patch was originally submitted
>by Guenther Deschner last September, and was then worked on by Rakesh Patel
>and myself. I've changed the names in kerberos_keytab.c file to reflect
>this. If anyone thinks I'm missing something else in the notice in
>kerberos_keytab.c, just let me know.
>
>The configure script now just uses a generic keytab name called 'WRFILE:api'.
>This should work fine because all we are really testing for is whether the
>Kerberos libraries want to use WRFILE: (MIT) or FILE: (Hiemdal). This should
>keep things within configure's directory. However, the krb5_kt_resolve does
>not (as far as I know) actually write anything. It merely creates a keytab
>structure that writes to that file only if a later krb5_XXX functions makes
>it do so.
>
>The MAX_KEYTAB_NAME_LEN is a constant defined in krb5.h, which states the
>maximum length of the pathname to a keytab file. I had defined this a few
>days ago debugging something that ended up being my own silly error - I took
>the define's for MAX_KEYTAB_NAME_LEN out. I also gave the code within the
>patch once last look over, and removed one other unused define
>(KRB5_KT_FILE_PREFIX).
>
>Let me know any other comments you may have.
>
>Thanks,
>Dan
>
>
>
>
>-----Original Message-----
>From: Andrew Bartlett [mailto:abartlet at samba.org]
>Sent: Monday, May 31, 2004 10:47 PM
>To: Dan Perry
>Cc: samba-technical at lists.samba.org
>Subject: RE: Patch: System keytab usage improvements
>
>On particular issues:
>
>Your configure test needs to be much more careful about security.
>Execute it in the build directory, at the very least, and perhaps use
>mkstemp():
>
>+ krb5_init_context(&context);
>+ if (krb5_kt_resolve(context, "WRFILE:/tmp/whatever", &keytab))
>+ exit(0);
>+ exit(1);
>
>(If there are systems with kerberos, but without mkstemp(), you can
>use our utility replacement)
>
>Also, did all these people really write your new kerberos_keytab.c?
>
>--- samba-3.0.5pre1/source/libads/kerberos_keytab.c 2004-05-06
>17:14:58.000000000 -0400
>+++ samba-3.0.5pre1/source/libads/kerberos_keytab.c 2004-05-31
>15:16:31.000000000 -0400
>@@ -0,0 +1,115 @@
>+/*
>+ Unix SMB/CIFS implementation.
>+ kerberos keytab utility library
>+ Copyright (C) Andrew Tridgell 2001
>+ Copyright (C) Remus Koos 2001
>+ Copyright (C) Luke Howard 2003
>+ Copyright (C) Guenther Deschner 2003
>+ Copyright (C) Jim McDonough (jmcd at us.ibm.com) 2003
>+
>+ This program is free software; you can redistribute it and/or modify
>+ it under the terms of the GNU General Public License as published by
>+ the Free Software Foundation; either version 2 of the License, or
>+ (at your option) any later version.
>
>Please don't do a copy & past of copyright notices, unless you really copied
>code.
>
>Is this magic number from somewhere? How do we know it won't change?
>--- samba-3.0.5pre1/source/utils/net_ads.c 2004-04-04 03:37:38.000000000
>-0400
>+++ samba-3.0.5pre1/source/utils/net_ads.c 2004-05-31 16:43:19.000000000
>-0400
>
>+#ifndef MAX_KEYTAB_NAME_LEN
>+#define MAX_KEYTAB_NAME_LEN 511
>+#endif
>
>
>
More information about the samba-technical
mailing list