On Fri, Nov 08, 2013 at 08:22:02AM -0500, Jeff Layton wrote: > On Fri, 08 Nov 2013 07:41:32 -0500 > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > No. I think the concern here, at least my concern, is the lack of management. > > We are forcing admins to use krb5i in lease management when its not necessary > > and there is no way to turn it off. > > > > I don't think that's really the case. The idea was to have the client > attempt to use krb5i if it's available, and then to fall back to > AUTH_SYS if it isn't. This would be *absolutely* no big deal if the > GSSAPI upcall succeeded or failed immediately instead of requiring this > timeout when the daemon isn't running. I'm also still a little confused about the security model. We discussed it before but I can't remember if it was really resolved. It makes sense to me as long as we insist on krb5i whenever we find a keytab. But my understanding was that with the current implementation it's possible we could find a keytab, attempt the krb5i connection, and *then* fallback silently on auth_sys if krb5i fails. Is that right? In that case I don't see the point of the krb5i any more: any attacker that can spoof rpc replies can force the fallback to auth_sys. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
