why are there two krb5_realm_params, in adm.h and admin.h?

[Chris Hecker]

> Is there any problem with just removing the dupe struct from adm.h,
> an then including kadm5/admin.h in kdc/main.c to get the struct
> declaration?

Well, this works fine, and is a trivial change.  Here's the patch.

Chris


=== modified file 'src/include/adm.h'
--- old/src/include/adm.h       2011-04-09 08:50:00 +0000
+++ new/src/include/adm.h       2011-07-26 22:19:37 +0000
@@ -190,35 +190,4 @@
  /* for krb5_key_salt_tuple */
  #include "kdb.h"

-/*
- * Data structure returned by krb5_read_realm_params()
- */
-typedef struct __krb5_realm_params {
-    char *              realm_profile;
-    char *              realm_mkey_name;
-    char *              realm_stash_file;
-    char *              realm_kdc_ports;
-    char *              realm_kdc_tcp_ports;
-    char *              realm_acl_file;
-    char *              realm_host_based_services;
-    char *              realm_no_host_referral;
-    krb5_int32          realm_kadmind_port;
-    krb5_enctype        realm_enctype;
-    krb5_deltat         realm_max_life;
-    krb5_deltat         realm_max_rlife;
-    krb5_timestamp      realm_expiration;
-    krb5_flags          realm_flags;
-    krb5_key_salt_tuple *realm_keysalts;
-    unsigned int        realm_reject_bad_transit:1;
-    unsigned int        realm_restrict_anon:1;
-    unsigned int        realm_kadmind_port_valid:1;
-    unsigned int        realm_enctype_valid:1;
-    unsigned int        realm_max_life_valid:1;
-    unsigned int        realm_max_rlife_valid:1;
-    unsigned int        realm_expiration_valid:1;
-    unsigned int        realm_flags_valid:1;
-    unsigned int        realm_reject_bad_transit_valid:1;
-    unsigned int        realm_restrict_anon_valid:1;
-    krb5_int32          realm_num_keysalts;
-} krb5_realm_params;
  #endif  /* KRB5_ADM_H__ */

=== modified file 'src/include/adm_proto.h'
--- old/src/include/adm_proto.h 2011-04-09 08:50:00 +0000
+++ new/src/include/adm_proto.h 2011-07-26 22:26:10 +0000
@@ -36,16 +36,12 @@
  typedef struct _krb5_db_entry krb5_db_entry;
  #endif  /* KRB5_KDB5__ */

-/* Ditto for adm.h */
+/* Ditto for admin.h */

-/*
- * XXXX krb5_realm params is defined in two header files!!!!
- * This really needs to be fixed!!!
- */
-#if !defined(KRB5_ADM_H__) && !defined(__KADM5_ADMIN_H__)
+#if !defined(__KADM5_ADMIN_H__)
  struct ___krb5_realm_params;
  typedef struct ___krb5_realm_params krb5_realm_params;
-#endif  /* KRB5_ADM_H__ */
+#endif  /* __KADM5_ADMIN_H__ */

  #ifndef KRB5_KDB5__
  struct ___krb5_key_salt_tuple;

=== modified file 'src/kdc/main.c'
--- old/src/kdc/main.c  2011-07-26 11:54:16 +0000
+++ new/src/kdc/main.c  2011-07-26 22:19:37 +0000
@@ -66,6 +66,7 @@
  #include "k5-int.h"
  #include "com_err.h"
  #include "adm.h"
+#include "kadm5/admin.h"
  #include "adm_proto.h"
  #include "kdc_util.h"
  #include "extern.h"





On 2011/07/26 15:12, Chris Hecker wrote:
>
> It looks like adm.h is only included in three files in the kdc right now
> (do_as_req.c, kdc_util.c, and main.c), and the krb5_realm_params from
> adm.h is actualy only used in main.c. Is there any problem with just
> removing the dupe struct from adm.h, an then including kadm5/admin.h in
> kdc/main.c to get the struct declaration?
>
> As my set of changes grows, making Greg more and more uncomfortable...
>
> :)
>
> Chris
>
>
> On 2011/07/26 15:03, Greg Hudson wrote:
>> On Tue, 2011-07-26 at 17:38 -0400, Chris Hecker wrote:
>>> If I want to add a bool flag to the realms section of kdc.conf, it seems
>>> like it should go in krb5_realm_params, but which struct should I
>>> modify? Both? How does this even compile? Are they just not ever both
>>> included in the same file? Is one exported to plugins or something and
>>> has to stay stable?
>>
>> This is an old mess which just hasn't been cleaned up. adm.h is used in
>> the KDC code; kadm5/admin.h is used everywhere else. adm.h isn't
>> installed and has no external stability guarantees, and would probably
>> be the one to go away in a more perfect tree. kadm5/admin.h is
>> installed but has explicitly weak stability guarantees.
>>
>> At the moment you'll need to make changes to both structures.
>>
>>
>>