Message-ID: <DCA0D71C-7828-4A80-8150-58AAF3B55E49@mit.edu>
From: Ken Raeburn <raeburn@MIT.EDU>
To: rt@krbdev.mit.edu
In-Reply-To: <rt-6516-31446.13.9624551363702@krbdev.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Subject: Re: [krbdev.mit.edu #6516] Re: Reading kerberos-adm from DNS (PATCH) 
MIME-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 26 Jun 2009 19:00:57 -0400
References: <rt-6516-31446.13.9624551363702@krbdev.mit.edu>
RT-Send-Cc: 
Content-Length: 3697

On Jun 21, 2009, at 13:42, megacz@cs.berkeley.edu via RT wrote:
> It seems that this patch didn't wind up in the recent kerberos
> release.  Do you think somebody could review it for inclusion soon, so
> that it has a chance of making it into the next release?  If any
> changes need to be made, please let me know and I will make them.

Hi, Adam.  I'm sorry it took so long to get back to this one.  I've  
looked at the patch in more detail, and see some problems in using it  
with the current code:

First, a minor point, the source code you're patching has changed.   
There are now a macro and helper function used to fetch a string  
parameter from either the command-line data or supplied profile.  That  
change probably doesn't need to be undone, it merely means the patch  
doesn't apply trivially.

Second, also a minor point, locate_server is going to check the  
profile referenced in the context.  It should use a subset of the  
config files supplied in the profile argument passed in, and in the  
same order, so it shouldn't get wrong results if the profile search  
has already failed, but it is doing redundant work.  That could be  
worked around a couple of ways -- supply an explicit profile to  
locate_server through yet another argument, or have it skip the use of  
the profile if the relevant string argument is instead a null  
pointer.  I haven't checked to see if that will do something  
reasonable when invoking service-location plugins though, and that  
should be supported here as well.  (Using locate_server will get that  
support, so it is the right way to go.)  If it turns out to be  
difficult or ugly, we can probably just live with the redundant checks  
for now and not worry about it; locating the kadmin server is rarely  
something performance-critical.

Third, more serious: One of the changes in the kadmin code in recent  
years was to add support for using kadmin/serverhostname as an  
alternative service principal name.  Logically, we should probably use  
the name presented in the SRV record, rather than having to go look  
the address up again in DNS.  (Currently kadm5_get_admin_service_name  
does use DNS to get the canonical name, but we should keep that  
mistake localized to one place where we can fix it later when we've  
got solid name canonicalization support, and we should use the same  
process for getting the principal name whether we got the host name  
from the config file or from DNS.  And, the CNAME processing done by  
gethostbyname is not necessarily going to give the same result that  
gethostbyaddr/getnameinfo will return for an address.)

This may get messier to fix than the others... I think we want all of  
the mechanisms that can be used to get a server address, including  
plugins (and the sample Python plugin) to supply a host name, probably  
in addition to the address, not instead of it.  This will probably  
mean changing some of the internal interfaces.  I'm uncertain whether  
that interface should permit a null pointer or empty string, and what  
that should mean -- should the library look up the address to get a  
name, or should it not fall back to host-based principal naming for  
that case?  And a smart plugin could know that for the KDC case we  
don't care about the host name, and omit it.  (Should it return a  
service principal name instead/too?)

Fourth, and related to ticket #5890, kadm5_get_admin_service_name will  
need tweaking for the DNS SRV usage, too; might as well fix the  
various problems at once.  (Or fix 5890 first, designing the changes  
with the future SRV support in mind.)

Ken

-- 
Ken Raeburn / raeburn@mit.edu / no longer at MIT Kerberos Consortium