Re: SP4_MACH_CRED

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Aug 01, 2013 at 03:24:05PM +0000, Adamson, Dros wrote:
> 
> On Aug 1, 2013, at 10:56 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> > On Thu, Aug 01, 2013 at 02:09:49PM +0000, Adamson, Dros wrote:
> >> 
> >> On Aug 1, 2013, at 10:03 AM, "Adamson, Dros" <Weston.Adamson@netapp.com>
> >> wrote:
> >> 
> >>> 
> >>> On Jul 31, 2013, at 7:48 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>> 
> >>>> On Wed, Jul 31, 2013 at 10:22:22PM +0000, Adamson, Dros wrote:
> >>>>> 
> >>>>> On Jul 31, 2013, at 5:39 PM, "J. Bruce Fields" <bfields@fieldses.org>
> >>>>> wrote:
> >>>>> 
> >>>>>> This should probably be cc'd to the mailing list.
> >>>>> 
> >>>>> Agreed!
> >>>>> 
> >>>>>> 
> >>>>>> On Wed, Jul 31, 2013 at 09:25:29PM +0000, Adamson, Dros wrote:
> >>>>>>> I have a pretty functional client-side SP4_MACH_CRED implementation
> >>>>>>> and I'm trying to implement the server side so I can fully test the
> >>>>>>> client code. I was testing against another server, but that didn't
> >>>>>>> implement any useful set of operations other than the required ones.
> >>>>>> 
> >>>>>> The latest Linux server implements SP4_MACH_CRED but only for the
> >>>>>> required operations.  (But that hasn't really been tested--any testing
> >>>>>> even to make sure that basic stuff works would be welcomed.)
> >>>>>> 
> >>>>> 
> >>>>> Right, I'm happy to report that the initial implementation of the required operations seems to work with (at least) one small patch I'll send your way soon.
> > 
> > (And I think I forgot to say thanks here!  It's useful to have that
> > tested.)
> 
> I should note it's somewhat useless to use SP4_MACH_CRED in this way from the linux client's perspective. We already use the machine cred with krb5i if possible for state manager ops even in SP4_NONE mode.

Without SP4_MACH_CRED anyone can e.g. destroy your client using just
auth_sys.

On its own all the use of krb5i really does is reassure you that your
rpc replies are from the server.

> > 	- user credentials go away before they're expected to expire.
> > 	(I wonder how this would typically happen?)
> 
> I don't believe this can happen yet.  IIRC a kdestroy isn't noticed by
> gssd, but this is probably going to change soon with Andy's keyring
> work, so it'd be nice to plan for it.

Yes.  I wonder if you could also take advantage of Andy's expiring-cred
emergency mode here?  So when you get the kdestroy notification, you
could try to flush writes before destroying contexts.

--b.