Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On 10/25/2011 2:19 PM, Jeffrey Hutzelman wrote:
> On Mon, 2011-10-24 at 22:36 -0500, Harry Coin wrote:
>>> Yes, you *can* use principal names of that form.  The GSS-API doesn't
>>> force you to.  And no GSS app that I know of forces you to use
>>> *client* principal names of that form (with the exception I've
>>> described before for root-equivalent access in the Solaris NFS
>>> server).
>> You do keep mentioning this.  sasl client and sasl server just do insist
>> otherwise.
> No, they don't.  They certainly expect you to use a GSS-API host-based
> _service_ name, which results in a host-based Kerberos service principal
> name like service/host.fqdn@REALM.  However, service names are not the
> same as client names, and not the same as usernames.

Technically that is of course true.   There is the issue that services 
must be in the business of owning files and that under names that are 
not 'root'.   That I happen to require that some of them be on the other 
side of NFS shares pushes the problem forward for me.   While indeed the 
case I could pick anything, the whole reverse DNS thing you don't like 
below means defacto it is unwise for me to do so here and now.

Moreover, there is a convention which identifies the principal as being 
'servicename/box'.  And code built right into rpcs that expect to get a 
uid:gid from the 'servicename' part.  I understand this is disliked.

At the bottom it remains the case that there are some principal names 
which are used outside one application.

I'm starting to understand that the tension I create here is that some 
think I'm suggesting what I'm doing is somehow normative or ought to 
be.    I am not.  I am tasked with getting this to work asap, not break 
anything that presently works, and secure the wire.   With the patches I 
just uploaded for freebsd (non root clients create root:client files if 
their passwd structure strings are more then 128 bytes).   I'm in 
'mission accomplished' mode.

You can leave me off of replies and responses, I'll browse the list from 
time to time to see if and when I can retire my patches in favor of 
something that doesn't break what already exists.

Thanks for all the care you all so obviously have for these ideas.

Harry