On 08/11/13 10:54, Chuck Lever wrote: > > On Nov 8, 2013, at 7:04 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > >> 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. > > The point is to use a consistent security flavor for lease management to avoid > NFS4ERR_CLID_INUSE. This really isn't about thwarting a MiTM attack on lease > management. Again, its not the technology I'm arguing because its good stuff... I would just like a way to manage it. > > The fallback mechanism can be fixed, somewhat. I've got a patch to have gssd return > ENOKEY if it can't find a machine credential. Then the kernel will use AUTH_SYS. We should not have to start a daemon to do a normal NFS client mount. That is just not a good thing... IMHO... > > The issue though is what to do in the other cases. Can gssd distinguish between the > case where the server has no Kerberos principal, and the case where gssd simply failed to > establish a GSS context? Or should we simply use the "sec=" setting in this > case and call it a day? Good questions.... IDK... I see this is another justification for use to have away to manage this code until these questions are answered. steved. > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > > > -- 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
