On Fri, May 03, 2013 at 02:48:59PM -0400, Chuck Lever wrote: > We should always use krb5i if a GSS context can be established with > our machine cred. As I said before, SETCLIENTID and > GETATTR(fs_locations) really should use an integrity-protecting > security flavor no matter what flavor is in effect on the mount points > themselves. Can you give an example of a threat that could be avoided by this? My suspicion is that in most cases an attacker with the ability to subvert auth_sys could *also* DOS gssd, and hence force the fallback to auth_sys. krb5i plus a fallback to auth_sys on failure to authenticate doesn't sound to me much more secure than just auth_sys. If we really want much security benefit from krb5i on state operations, I think we need to really *require* krb5i. So I'm inclined towards Jeff's solution: don't do this unless userspace somehow affirmatively states that it requires krb5i on state operations. I agree that we should default to this when we can. But the way to move towards that default is then to get distributions to turn on the new module parm (or whatever it is) by default. As they do so, they can also ensure that e.g. gssd is started. --b. > > Instead of using AUTH_GSS for SETCLIENTID by default, would it make > > sense to add a switch (module parm?) that turns it on so that it can be > > an opt-in thing rather than doing this by default? > > Why add another tunable when we really should just fix the delay? > > Besides, if gssd is running and no keytab exists, then the fallback to AUTH_SYS should be fast. Is that not an effective workaround until we address the delay problem? > > -- > 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 -- 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
