To: krb5-bugs@mit.edu
Cc: Kevin Coffman <kwc@citi.umich.edu>, Andy Adamson <andros@citi.umich.edu>
Subject: rpcsec_gss compliant rpc replacement
Date: Mon, 10 Feb 2003 09:27:06 -0500
From: Kevin Coffman <kwc@citi.umich.edu>

There are two files available via

    http://www.citi.umich.edu/projects/nfsv4/mit_patches

which are a drop-in replacement for the src/lib/rpc directory
(including unit-test) and a patch file to the remaining code to utilize
the new rpc code in the kadmin/kadmind.  This code has been tested
successfully against Sun's SEAM kadmind/kadmin.  The patch file is from
an 11/08/02 snapshot release.  I hope this is recent enough.


--
Kevin Coffman           Center for Information Technology Integration
----------------------  University of Michigan
Phone: (734) 763-0592   3106 Argus
mailto:kwc@umich.edu    535 West William Street
----------------------  Ann Arbor, MI, 48103-4943
http://www.citi.umich.edu/u/kwc/

To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #1349] Initial comments on umich RPC
Date: Wed, 20 Aug 2003 17:07:30 -0400 (EDT)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc: 




As an internal note, we need to make sure that we pick up the security
fixes to rpc from the first part of this year as we integrate these
patches.


The handling of the minimum lifetime for kpasswd is broken.  An
internal API from the server library is improperly duplicated in
src/kadmin/server/misc.c, and a prototype is randomly added to another
(non-header) file to access this.  We need a cleaner way of getting at
the code.

The ifdef style is kind of unfortunate.  Rather than removing old
code, the patches add ifdefs which should either be always true or
always false as I understand things.  If there are cases where you
might define the ifdefs other than one way, I'd like to understand how
that would work.  If my understanding is correct, I can run unifdef as
I apply the patches.


The changes related to using kadmin/fqdn instead of kadmin/admin are a
bit more far-reaching than I had hoped.  I am also concerned they may
create problems for multi-homed admin servers and may create a support
load we don't want to deal with.  I will revisit that issue on krbdev.


I have not yet audited (or even decided what approach if any to use in
order to audit) the actual RPC code.  All I've done so far is to look
at the diffs to the rest of krb5.  We need to at least confirm that
the RPC does not interact badly with an RPC from libc.

To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1349] Initial comments on umich RPC 
Date: Thu, 21 Aug 2003 09:02:58 -0400
From: Kevin Coffman <kwc@citi.umich.edu>
RT-Send-Cc: 

> The ifdef style is kind of unfortunate.  Rather than removing old
> code, the patches add ifdefs which should either be always true or
> always false as I understand things.  If there are cases where you
> might define the ifdefs other than one way, I'd like to understand how
> that would work.  If my understanding is correct, I can run unifdef as
> I apply the patches.


My initial thought was that you might want to support a configure option
of which rpc library to use.  Thinking about it now, it sounds like a
support nightmare.  So yes, unifdef is probably the way to go.


> The changes related to using kadmin/fqdn instead of kadmin/admin are a
> bit more far-reaching than I had hoped.  I am also concerned they may
> create problems for multi-homed admin servers and may create a support
> load we don't want to deal with.  I will revisit that issue on krbdev.

I believe the bulk of the changes were in the testcases.  Many of those
changes were due to the change to use the non-rpc based kpasswd in the
tests, not because of the kadmin principal change.

To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1349] Initial comments on umich RPC
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 21 Aug 2003 12:48:27 -0400
RT-Send-Cc: 

>>>>> "kwc@citi" == kwc@citi umich edu via RT <rt-comment@krbdev.mit.edu> writes:

    >> The changes related to using kadmin/fqdn instead of
    >> kadmin/admin are a bit more far-reaching than I had hoped.  I
    >> am also concerned they may create problems for multi-homed
    >> admin servers and may create a support load we don't want to
    >> deal with.  I will revisit that issue on krbdev.

    kwc@citi> I believe the bulk of the changes were in the testcases.
    kwc@citi> Many of those changes were due to the change to use the
    kwc@citi> non-rpc based kpasswd in the tests, not because of the
    kwc@citi> kadmin principal change.


No, I'm actually thinking of:

* an API change to take the principal

* A change to generate the right principal in each client application.

* A dependence on a gethostname/gethostbyname pair in each application.
* A change to generate the kadmin key  for the current hostname in
kdb5_util create.

Will have the rest of the discussion on krbdev.