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

On Tue, 2011-10-25 at 14:29 -0500, Harry Coin wrote:
> 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. 

No, not at all.
But a significant source of tension is that you have

1) adopted certain conventions:
   a) making the name of the user a service runs as be the same as
      the service name used for accepting Kerberos authentication
   b) making the client principal name a user uses to authenticate to
      NFS be the same as the service principal name used by services
      running as that user to accept Kerberos authentication
   c) adopting a convention of using names like "foo/box.fqdn"
      for a client principal used by user foo on system box.

2) Accepted those conventions as constraints on your environment.

3) Asserted that these constraints are imposed by GSS-API or SASL
   or NFS or some other component of the system, when in fact they
   are constraints you have chosen to adopt, or been forced to adopt
   by other factors in your organization or environment, or some
   combination.

Nico's comments notwithstanding, all of the conventions listed in (1)
are reasonable things to adopt, but they are all of your own invention.
However, if you're going to adopt (1c), you do need to be very careful,
because sooner or later you're going to have a collision between some
existing user and some new service you haven't thought of.  That's fine
right up until you discover that some service simply _must_ have a
particular host-based principal name for interoperability, but you've
already used the corresponding username for something else and will have
a hard time changing.  Then, well, good luck.

It's also entirely reasonable to place whatever constraints you want on
solutions you come up with.  But, it is not reasonable to complain that
you _have_ to do things a certain way because Kerberos/SASL/GSS/whatever
"insists", when the constraint actually came from you.  And, you have to
expect that your proposals will get some pushback when you present them
this way.

If you'd said "we want to..." instead of "GSS-API forces us to...", your
suggestions and patches would likely have been much better received.


In the meantime, what Nico and, to a lesser extent, I have been trying
to do is twofold:

1) Disabuse you of the notion that some of the conventions you've
   adopted are somehow required by GSS-API or common in the rest of the
   world.  Some of those things are making your life harder than we
   think it needs to be, and often people's lives get a lot easier once
   they realize that something they thought was a requirement really is
   just a convention, or something they misinterpreted, or something
   that some one piece of software does strangely, like Sun's root/host
   thing.

   I would note that if you'd started with "we want to..." instead of
   "GSS-API forces us to...", there'd have been a lot less of this.  We
   might still have tried to convince you there's an easier way, but at
   least we wouldn't be arguing about whether you _have_ to do things
   some particular way.


2) Provide feedback on the patches you've submitted.  The features you
   have proposed aren't necessarily bad, but there are problems.  For
   example, your krb5_aname2lname enhancements work only under the
   assumption that a common and reasonable situation will not arise.

   If you're going to submit patches to a software project, you need to
   expect some feedback and that not everything will be accepted right
   away, or even at all.  I've submitted patches to projects where the
   maintainer responded, literally,  "no way in hell".  That was a
   well-formed patch, from someone the maintainer had heard of and who
   already had other code in the project.  And he was right -- I had
   made an assumption that could not be counted upon to be true in all
   of the wide variety of situations in which the code might run.

-- Jeff