On Nov 8, 2013, at 9:58 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Nov 8, 2013, at 8:14 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > >> On Fri, Nov 08, 2013 at 07:54:19AM -0800, 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. >> >> OK, but then you still do want to ensure you thwart that attack in the >> case krb5 is explicitly asked for. >> >> So for example does a krb5 mount fail if a previous non-krb5 mount fell >> back on auth_sys for clientid establishment? >> >>> 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. >> >> To get that right you'd then need to fail on errors *other* than ENOKEY. >> Since old gssd doesn't return ENOKEY that would mean failing all >> auth_sys mounts on kernel upgrade, wouldn't it? >> >>> 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? >> >> I don't know. I suppose the client should get some kind of >> no-such-principal error and use that. >> >>> Or should we simply use the "sec=" setting in this case and >>> call it a day? >> >> I think falling back works as long as we still are strict in the case >> the mount explicitly requests some security and don't just use >> whatever's already established in that case. > > Agreed. That is what we want to strive for. > > So: use the fallback mechanism only if Kerberos was _not_ specified via the mount options, I think? > >> And if we do that then I don't think the ENOKEY/no-such-principal cases >> are worth sorting out. The fly in this ointment is allowing clients with no keytab to mount with sec=krb5. We can use ENOKEY to allow lease management with AUTH_SYS but data access using Kerberos and a user's credential. Otherwise, a user has to login as root, kinit as themselves, and then mount. That makes automounter configurations a little dodgy. -- 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
