| Message ID | 1378235929-4710-1-git-send-email-dros@netapp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: > Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression > that causes SECINFO to fail without actualy sending an RPC if: > > 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) > 2) the current user doesn't have valid kerberos credentials > > This situation is quite common - as of now a sec=sys mount would use > krb5i for the nfs_client's rpc_client and a user would hardly be faulted > for not having run kinit. > > The solution is to use the machine cred when trying to use an integrity > protected auth flavor for SECINFO. > > Older servers may not support using the machine cred or an integrity > protected auth flavor for SECINFO in every circumstance, so we fall back > to using the user's cred and the filesystem's auth flavor in this case. > > We run into another problem when running against linux nfs servers - > they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the > mount is also that flavor) even though that is not a valid error for > SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO > by falling back to using the user cred and the filesystem's auth flavor. > > Signed-off-by: Weston Andros Adamson <dros@netapp.com> > --- Thanks! Applied... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: >> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression >> that causes SECINFO to fail without actualy sending an RPC if: >> >> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) >> 2) the current user doesn't have valid kerberos credentials >> >> This situation is quite common - as of now a sec=sys mount would use >> krb5i for the nfs_client's rpc_client and a user would hardly be faulted >> for not having run kinit. >> >> The solution is to use the machine cred when trying to use an integrity >> protected auth flavor for SECINFO. >> >> Older servers may not support using the machine cred or an integrity >> protected auth flavor for SECINFO in every circumstance, so we fall back >> to using the user's cred and the filesystem's auth flavor in this case. >> >> We run into another problem when running against linux nfs servers - >> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the >> mount is also that flavor) even though that is not a valid error for >> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO >> by falling back to using the user cred and the filesystem's auth flavor. >> >> Signed-off-by: Weston Andros Adamson <dros@netapp.com> >> --- > > Thanks! Applied… Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? -dros > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 3, 2013, at 3:30 PM, "Adamson, Dros" <Weston.Adamson@netapp.com> wrote: > > On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> > wrote: > >> On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: >>> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression >>> that causes SECINFO to fail without actualy sending an RPC if: >>> >>> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) >>> 2) the current user doesn't have valid kerberos credentials >>> >>> This situation is quite common - as of now a sec=sys mount would use >>> krb5i for the nfs_client's rpc_client and a user would hardly be faulted >>> for not having run kinit. >>> >>> The solution is to use the machine cred when trying to use an integrity >>> protected auth flavor for SECINFO. >>> >>> Older servers may not support using the machine cred or an integrity >>> protected auth flavor for SECINFO in every circumstance, so we fall back >>> to using the user's cred and the filesystem's auth flavor in this case. >>> >>> We run into another problem when running against linux nfs servers - >>> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the >>> mount is also that flavor) even though that is not a valid error for >>> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO >>> by falling back to using the user cred and the filesystem's auth flavor. >>> >>> Signed-off-by: Weston Andros Adamson <dros@netapp.com> >>> --- >> >> Thanks! Applied… > > Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? > > Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? > NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? … or does it seem reasonable to also retry with the user cred (and filesystem's auth flavor) when the krb5i SECINFO results in NFS4ERR_ACCESS as well as the (out of spec) WRONGSEC? Thanks, -dros > > -dros > >> >> -- >> Trond Myklebust >> Linux NFS client maintainer >> >> NetApp >> Trond.Myklebust@netapp.com >> www.netapp.com > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote: > On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> > wrote: > > > On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: > >> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression > >> that causes SECINFO to fail without actualy sending an RPC if: > >> > >> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) > >> 2) the current user doesn't have valid kerberos credentials > >> > >> This situation is quite common - as of now a sec=sys mount would use > >> krb5i for the nfs_client's rpc_client and a user would hardly be faulted > >> for not having run kinit. > >> > >> The solution is to use the machine cred when trying to use an integrity > >> protected auth flavor for SECINFO. > >> > >> Older servers may not support using the machine cred or an integrity > >> protected auth flavor for SECINFO in every circumstance, so we fall back > >> to using the user's cred and the filesystem's auth flavor in this case. > >> > >> We run into another problem when running against linux nfs servers - > >> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the > >> mount is also that flavor) even though that is not a valid error for > >> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO > >> by falling back to using the user cred and the filesystem's auth flavor. > >> > >> Signed-off-by: Weston Andros Adamson <dros@netapp.com> > >> --- > > > > Thanks! Applied… > > Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? > > Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? > NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? If the server doesn't support krb5i, then it won't even be able to receive our RPC call, so it can at best reply with an AUTH_BADCRED rpc level error, which rpc_verify_header() will translate as EACCES. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote: >> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> >> wrote: >> >>> On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: >>>> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression >>>> that causes SECINFO to fail without actualy sending an RPC if: >>>> >>>> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) >>>> 2) the current user doesn't have valid kerberos credentials >>>> >>>> This situation is quite common - as of now a sec=sys mount would use >>>> krb5i for the nfs_client's rpc_client and a user would hardly be faulted >>>> for not having run kinit. >>>> >>>> The solution is to use the machine cred when trying to use an integrity >>>> protected auth flavor for SECINFO. >>>> >>>> Older servers may not support using the machine cred or an integrity >>>> protected auth flavor for SECINFO in every circumstance, so we fall back >>>> to using the user's cred and the filesystem's auth flavor in this case. >>>> >>>> We run into another problem when running against linux nfs servers - >>>> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the >>>> mount is also that flavor) even though that is not a valid error for >>>> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO >>>> by falling back to using the user cred and the filesystem's auth flavor. >>>> >>>> Signed-off-by: Weston Andros Adamson <dros@netapp.com> >>>> --- >>> >>> Thanks! Applied… >> >> Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? >> >> Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? >> NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? > > If the server doesn't support krb5i, then it won't even be able to > receive our RPC call, so it can at best reply with an AUTH_BADCRED rpc > level error, which rpc_verify_header() will translate as EACCES. What if the server supports RPCSEC_GSS, but the export options specify only sec=sys?
On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote: >> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> >> wrote: >> >>> On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: >>>> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression >>>> that causes SECINFO to fail without actualy sending an RPC if: >>>> >>>> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) >>>> 2) the current user doesn't have valid kerberos credentials >>>> >>>> This situation is quite common - as of now a sec=sys mount would use >>>> krb5i for the nfs_client's rpc_client and a user would hardly be faulted >>>> for not having run kinit. >>>> >>>> The solution is to use the machine cred when trying to use an integrity >>>> protected auth flavor for SECINFO. >>>> >>>> Older servers may not support using the machine cred or an integrity >>>> protected auth flavor for SECINFO in every circumstance, so we fall back >>>> to using the user's cred and the filesystem's auth flavor in this case. >>>> >>>> We run into another problem when running against linux nfs servers - >>>> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the >>>> mount is also that flavor) even though that is not a valid error for >>>> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO >>>> by falling back to using the user cred and the filesystem's auth flavor. >>>> >>>> Signed-off-by: Weston Andros Adamson <dros@netapp.com> >>>> --- >>> >>> Thanks! Applied… >> >> Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? >> >> Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? >> NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? > > If the server doesn't support krb5i, then it won't even be able to > receive our RPC call, so it can at best reply with an AUTH_BADCRED rpc > level error, which rpc_verify_header() will translate as EACCES. I'm sorry, I mean if the server supports krb5i, but not for SECINFO. If the server doesn't support krb5i or there is a misconfiguration / time skew /etc, the client won't be using krb5i for the nfs_client's rpc_client and we'll never attempt to use it for SECINFO. -dros > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gVHVlLCAyMDEzLTA5LTAzIGF0IDE1OjQwIC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g T24gU2VwIDMsIDIwMTMsIGF0IDM6MzkgUE0sICJNeWtsZWJ1c3QsIFRyb25kIiA8VHJvbmQuTXlr bGVidXN0QG5ldGFwcC5jb20+IHdyb3RlOg0KPiANCj4gPiBPbiBUdWUsIDIwMTMtMDktMDMgYXQg MTk6MzAgKzAwMDAsIEFkYW1zb24sIERyb3Mgd3JvdGU6DQo+ID4+IE9uIFNlcCAzLCAyMDEzLCBh dCAzOjI1IFBNLCAiTXlrbGVidXN0LCBUcm9uZCIgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29t Pg0KPiA+PiB3cm90ZToNCj4gPj4gDQo+ID4+PiBPbiBUdWUsIDIwMTMtMDktMDMgYXQgMTU6MTgg LTA0MDAsIFdlc3RvbiBBbmRyb3MgQWRhbXNvbiB3cm90ZToNCj4gPj4+PiBDb21taXQgNWVjMTZh ODUwMGQzMzliMGU3YTBjYzc2Yjc4NWQxOGRhYWQzNTRkNCBpbnRyb2R1Y2VkIGEgcmVncmVzc2lv bg0KPiA+Pj4+IHRoYXQgY2F1c2VzIFNFQ0lORk8gdG8gZmFpbCB3aXRob3V0IGFjdHVhbHkgc2Vu ZGluZyBhbiBSUEMgaWY6DQo+ID4+Pj4gDQo+ID4+Pj4gMSkgdGhlIG5mc19jbGllbnQncyBycGNf Y2xpZW50IHdhcyB1c2luZyBLUkI1aS9wIChub3cgdHJpZWQgYnkgZGVmYXVsdCkNCj4gPj4+PiAy KSB0aGUgY3VycmVudCB1c2VyIGRvZXNuJ3QgaGF2ZSB2YWxpZCBrZXJiZXJvcyBjcmVkZW50aWFs cw0KPiA+Pj4+IA0KPiA+Pj4+IFRoaXMgc2l0dWF0aW9uIGlzIHF1aXRlIGNvbW1vbiAtIGFzIG9m IG5vdyBhIHNlYz1zeXMgbW91bnQgd291bGQgdXNlDQo+ID4+Pj4ga3JiNWkgZm9yIHRoZSBuZnNf Y2xpZW50J3MgcnBjX2NsaWVudCBhbmQgYSB1c2VyIHdvdWxkIGhhcmRseSBiZSBmYXVsdGVkDQo+ ID4+Pj4gZm9yIG5vdCBoYXZpbmcgcnVuIGtpbml0Lg0KPiA+Pj4+IA0KPiA+Pj4+IFRoZSBzb2x1 dGlvbiBpcyB0byB1c2UgdGhlIG1hY2hpbmUgY3JlZCB3aGVuIHRyeWluZyB0byB1c2UgYW4gaW50 ZWdyaXR5DQo+ID4+Pj4gcHJvdGVjdGVkIGF1dGggZmxhdm9yIGZvciBTRUNJTkZPLg0KPiA+Pj4+ IA0KPiA+Pj4+IE9sZGVyIHNlcnZlcnMgbWF5IG5vdCBzdXBwb3J0IHVzaW5nIHRoZSBtYWNoaW5l IGNyZWQgb3IgYW4gaW50ZWdyaXR5DQo+ID4+Pj4gcHJvdGVjdGVkIGF1dGggZmxhdm9yIGZvciBT RUNJTkZPIGluIGV2ZXJ5IGNpcmN1bXN0YW5jZSwgc28gd2UgZmFsbCBiYWNrDQo+ID4+Pj4gdG8g dXNpbmcgdGhlIHVzZXIncyBjcmVkIGFuZCB0aGUgZmlsZXN5c3RlbSdzIGF1dGggZmxhdm9yIGlu IHRoaXMgY2FzZS4NCj4gPj4+PiANCj4gPj4+PiBXZSBydW4gaW50byBhbm90aGVyIHByb2JsZW0g d2hlbiBydW5uaW5nIGFnYWluc3QgbGludXggbmZzIHNlcnZlcnMgLQ0KPiA+Pj4+IHRoZXkgcmV0 dXJuIE5GUzRFUlJfV1JPTkdTRUMgd2hlbiB1c2luZyBpbnRlZ3JpdHkgYXV0aCBmbGF2b3IgKHVu bGVzcyB0aGUNCj4gPj4+PiBtb3VudCBpcyBhbHNvIHRoYXQgZmxhdm9yKSBldmVuIHRob3VnaCB0 aGF0IGlzIG5vdCBhIHZhbGlkIGVycm9yIGZvcg0KPiA+Pj4+IFNFQ0lORk8qLiAgRXZlbiB0aG91 Z2ggaXQncyBhZ2FpbnN0IHNwZWMsIGhhbmRsZSBXUk9OR1NFQyBlcnJvcnMgb24gU0VDSU5GTw0K PiA+Pj4+IGJ5IGZhbGxpbmcgYmFjayB0byB1c2luZyB0aGUgdXNlciBjcmVkIGFuZCB0aGUgZmls ZXN5c3RlbSdzIGF1dGggZmxhdm9yLg0KPiA+Pj4+IA0KPiA+Pj4+IFNpZ25lZC1vZmYtYnk6IFdl c3RvbiBBbmRyb3MgQWRhbXNvbiA8ZHJvc0BuZXRhcHAuY29tPg0KPiA+Pj4+IC0tLQ0KPiA+Pj4g DQo+ID4+PiBUaGFua3MhIEFwcGxpZWTigKYNCj4gPj4gDQo+ID4+IE9oLCBzb3JyeSwgSSB3YXMg aG9waW5nIHRvIGZvc3RlciBtb3JlIGRpc2N1c3Npb24gYXJvdW5kIENodWNrJ3MgY29tbWVudHMg dG8gdGhlIG5mc2Qgc2lkZSBvZiB0aGlzIGVmZm9ydCBiZWZvcmUgYWRkaW5nIHRoaXMsIGFsdGhv dWdoIGl0J3MgYmV0dGVyIHRoYW4gdGhlIHN0YXRlIHRoZSBjbGllbnQgd2FzIGluIHNpbmNlIDVl YzE2YTg1MDBkMzM5YjBlN2EwY2M3NmI3ODVkMThkYWFkMzU0ZDQuICBTaG91bGQgSSBwb3N0IHRo ZSBzaW1pbGFyIHBhdGNoZXMgZm9yIFNFQ0lORk9fTk9OQU1FIGFuZCBMQVlPVVRHRVQ/DQo+ID4+ IA0KPiA+PiBTcGVjaWZpY2FsbHksIENodWNrJ3MgKHZlcnkgdmFsaWQpIHBvaW50IGlzIHdoYXQg ZXJyb3Igc2hvdWxkIGEgc2VydmVyIHJldHVybiB0byBTRUNJTkZPIHVzaW5nIGtyYjVpIGlmIGl0 IGRvZXNuJ3Qgc3VwcG9ydCB0aGF0IGF1dGggZmxhdm9yPyAgIA0KPiA+PiBORlM0RVJSX0FDQ0VT UyBsb29rcyBsaWtlIHRoZSBiZXN0IGF2YWlsYWJsZSBvcHRpb24gdG8gbWUgLS0gc2hvdWxkIEkg dGFrZSB0aGlzIHRvIHRoZSBJRVRGIGxpc3Q/DQo+ID4gDQo+ID4gSWYgdGhlIHNlcnZlciBkb2Vz bid0IHN1cHBvcnQga3JiNWksIHRoZW4gaXQgd29uJ3QgZXZlbiBiZSBhYmxlIHRvDQo+ID4gcmVj ZWl2ZSBvdXIgUlBDIGNhbGwsIHNvIGl0IGNhbiBhdCBiZXN0IHJlcGx5IHdpdGggYW4gQVVUSF9C QURDUkVEIHJwYw0KPiA+IGxldmVsIGVycm9yLCB3aGljaCBycGNfdmVyaWZ5X2hlYWRlcigpIHdp bGwgdHJhbnNsYXRlIGFzIEVBQ0NFUy4NCj4gDQo+IFdoYXQgaWYgdGhlIHNlcnZlciBzdXBwb3J0 cyBSUENTRUNfR1NTLCBidXQgdGhlIGV4cG9ydCBvcHRpb25zIHNwZWNpZnkgb25seSBzZWM9c3lz Pw0KDQpSRkM1NjYxIHNwZWNpZmljYWxseSBzdGF0ZXMgdGhhdCBpdCBzaG91bGQgYWNjZXB0IHRo ZSBTRUNJTkZPIGNhbGwgd2l0aA0KUlBDU0VDX0dTUyBpbiB0aGF0IGNhc2UuDQoNClJGQzM1MzBi aXMgZG9lcyB0b28sIGJ1dCB0aGVyZSBtYXkgYmUgYSBsZWdhY3kgUkZDMzUzMCBpc3N1ZSB0aGVy ZS4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0K DQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 3, 2013, at 3:52 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Tue, 2013-09-03 at 15:40 -0400, Chuck Lever wrote: >> On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: >> >>> On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote: >>>> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> >>>> wrote: >>>> >>>>> On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: >>>>>> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression >>>>>> that causes SECINFO to fail without actualy sending an RPC if: >>>>>> >>>>>> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) >>>>>> 2) the current user doesn't have valid kerberos credentials >>>>>> >>>>>> This situation is quite common - as of now a sec=sys mount would use >>>>>> krb5i for the nfs_client's rpc_client and a user would hardly be faulted >>>>>> for not having run kinit. >>>>>> >>>>>> The solution is to use the machine cred when trying to use an integrity >>>>>> protected auth flavor for SECINFO. >>>>>> >>>>>> Older servers may not support using the machine cred or an integrity >>>>>> protected auth flavor for SECINFO in every circumstance, so we fall back >>>>>> to using the user's cred and the filesystem's auth flavor in this case. >>>>>> >>>>>> We run into another problem when running against linux nfs servers - >>>>>> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the >>>>>> mount is also that flavor) even though that is not a valid error for >>>>>> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO >>>>>> by falling back to using the user cred and the filesystem's auth flavor. >>>>>> >>>>>> Signed-off-by: Weston Andros Adamson <dros@netapp.com> >>>>>> --- >>>>> >>>>> Thanks! Applied… >>>> >>>> Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? >>>> >>>> Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? >>>> NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? >>> >>> If the server doesn't support krb5i, then it won't even be able to >>> receive our RPC call, so it can at best reply with an AUTH_BADCRED rpc >>> level error, which rpc_verify_header() will translate as EACCES. >> >> What if the server supports RPCSEC_GSS, but the export options specify only sec=sys? > > RFC5661 specifically states that it should accept the SECINFO call with > RPCSEC_GSS in that case. > > RFC3530bis does too, but there may be a legacy RFC3530 issue there. I guess as far as this patch (and forthcoming SECINFO_NONAME) goes, do we want to retry (falling back to user cred) on NFS4ERR_ACCESS too? -dros > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2013-09-03 at 19:55 +0000, Adamson, Dros wrote: > On Sep 3, 2013, at 3:52 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > > > On Tue, 2013-09-03 at 15:40 -0400, Chuck Lever wrote: > >> On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > >> > >>> On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote: > >>>> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> > >>>> wrote: > >>>> > >>>>> On Tue, 2013-09-03 at 15:18 -0400, Weston Andros Adamson wrote: > >>>>>> Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression > >>>>>> that causes SECINFO to fail without actualy sending an RPC if: > >>>>>> > >>>>>> 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) > >>>>>> 2) the current user doesn't have valid kerberos credentials > >>>>>> > >>>>>> This situation is quite common - as of now a sec=sys mount would use > >>>>>> krb5i for the nfs_client's rpc_client and a user would hardly be faulted > >>>>>> for not having run kinit. > >>>>>> > >>>>>> The solution is to use the machine cred when trying to use an integrity > >>>>>> protected auth flavor for SECINFO. > >>>>>> > >>>>>> Older servers may not support using the machine cred or an integrity > >>>>>> protected auth flavor for SECINFO in every circumstance, so we fall back > >>>>>> to using the user's cred and the filesystem's auth flavor in this case. > >>>>>> > >>>>>> We run into another problem when running against linux nfs servers - > >>>>>> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the > >>>>>> mount is also that flavor) even though that is not a valid error for > >>>>>> SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO > >>>>>> by falling back to using the user cred and the filesystem's auth flavor. > >>>>>> > >>>>>> Signed-off-by: Weston Andros Adamson <dros@netapp.com> > >>>>>> --- > >>>>> > >>>>> Thanks! Applied… > >>>> > >>>> Oh, sorry, I was hoping to foster more discussion around Chuck's comments to the nfsd side of this effort before adding this, although it's better than the state the client was in since 5ec16a8500d339b0e7a0cc76b785d18daad354d4. Should I post the similar patches for SECINFO_NONAME and LAYOUTGET? > >>>> > >>>> Specifically, Chuck's (very valid) point is what error should a server return to SECINFO using krb5i if it doesn't support that auth flavor? > >>>> NFS4ERR_ACCESS looks like the best available option to me -- should I take this to the IETF list? > >>> > >>> If the server doesn't support krb5i, then it won't even be able to > >>> receive our RPC call, so it can at best reply with an AUTH_BADCRED rpc > >>> level error, which rpc_verify_header() will translate as EACCES. > >> > >> What if the server supports RPCSEC_GSS, but the export options specify only sec=sys? > > > > RFC5661 specifically states that it should accept the SECINFO call with > > RPCSEC_GSS in that case. > > > > RFC3530bis does too, but there may be a legacy RFC3530 issue there. > > I guess as far as this patch (and forthcoming SECINFO_NONAME) goes, do we want to retry (falling back to user cred) on NFS4ERR_ACCESS too? SECINFO_NO_NAME is covered by RFC5661, so there should be no legacy problems (only server bugs). The current code should therefore be correct without any need for changes. The only potential problem is SECINFO itself for the NFSv4.0 case. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index f7c8106..e54b992 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -435,6 +435,20 @@ wait_on_recovery: return ret; } +/* + * Return 'true' if 'clp' is using an rpc_client that is integrity protected + * or 'false' otherwise. + */ +static bool _nfs4_is_integrity_protected(struct nfs_client *clp) +{ + rpc_authflavor_t flavor = clp->cl_rpcclient->cl_auth->au_flavor; + + if (flavor == RPC_AUTH_GSS_KRB5I || + flavor == RPC_AUTH_GSS_KRB5P) + return true; + + return false; +} static void do_renew_lease(struct nfs_client *clp, unsigned long timestamp) { @@ -5840,10 +5854,13 @@ int nfs4_proc_fs_locations(struct rpc_clnt *client, struct inode *dir, } /** - * Use the state managment nfs_client cl_rpcclient, which uses krb5i (if - * possible) as per RFC3530bis and RFC5661 Security Considerations sections + * If 'use_integrity' is true and the state managment nfs_client + * cl_rpcclient is using krb5i/p, use the integrity protected cl_rpcclient + * and the machine credential as per RFC3530bis and RFC5661 Security + * Considerations sections. Otherwise, just use the user cred with the + * filesystem's rpc_client. */ -static int _nfs4_proc_secinfo(struct inode *dir, const struct qstr *name, struct nfs4_secinfo_flavors *flavors) +static int _nfs4_proc_secinfo(struct inode *dir, const struct qstr *name, struct nfs4_secinfo_flavors *flavors, bool use_integrity) { int status; struct nfs4_secinfo_arg args = { @@ -5858,11 +5875,21 @@ static int _nfs4_proc_secinfo(struct inode *dir, const struct qstr *name, struct .rpc_argp = &args, .rpc_resp = &res, }; - struct rpc_clnt *clnt = NFS_SERVER(dir)->nfs_client->cl_rpcclient; + struct rpc_clnt *clnt = NFS_SERVER(dir)->client; + + if (use_integrity) { + clnt = NFS_SERVER(dir)->nfs_client->cl_rpcclient; + msg.rpc_cred = nfs4_get_clid_cred(NFS_SERVER(dir)->nfs_client); + } dprintk("NFS call secinfo %s\n", name->name); - status = nfs4_call_sync(clnt, NFS_SERVER(dir), &msg, &args.seq_args, &res.seq_res, 0); + status = nfs4_call_sync(clnt, NFS_SERVER(dir), &msg, &args.seq_args, + &res.seq_res, 0); dprintk("NFS reply secinfo: %d\n", status); + + if (msg.rpc_cred) + put_rpccred(msg.rpc_cred); + return status; } @@ -5872,7 +5899,21 @@ int nfs4_proc_secinfo(struct inode *dir, const struct qstr *name, struct nfs4_exception exception = { }; int err; do { - err = _nfs4_proc_secinfo(dir, name, flavors); + err = -NFS4ERR_WRONGSEC; + + /* try to use integrity protection with machine cred */ + if (_nfs4_is_integrity_protected(NFS_SERVER(dir)->nfs_client)) + err = _nfs4_proc_secinfo(dir, name, flavors, true); + + /* + * if unable to use integrity protection, or SECINFO with + * integrity protection returns NFS4ERR_WRONGSEC (which is + * disallowed by spec, but exists in deployed servers) use + * the current filesystem's rpc_client and the user cred. + */ + if (err == -NFS4ERR_WRONGSEC) + err = _nfs4_proc_secinfo(dir, name, flavors, false); + trace_nfs4_secinfo(dir, name, err); err = nfs4_handle_exception(NFS_SERVER(dir), err, &exception);
Commit 5ec16a8500d339b0e7a0cc76b785d18daad354d4 introduced a regression that causes SECINFO to fail without actualy sending an RPC if: 1) the nfs_client's rpc_client was using KRB5i/p (now tried by default) 2) the current user doesn't have valid kerberos credentials This situation is quite common - as of now a sec=sys mount would use krb5i for the nfs_client's rpc_client and a user would hardly be faulted for not having run kinit. The solution is to use the machine cred when trying to use an integrity protected auth flavor for SECINFO. Older servers may not support using the machine cred or an integrity protected auth flavor for SECINFO in every circumstance, so we fall back to using the user's cred and the filesystem's auth flavor in this case. We run into another problem when running against linux nfs servers - they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless the mount is also that flavor) even though that is not a valid error for SECINFO*. Even though it's against spec, handle WRONGSEC errors on SECINFO by falling back to using the user cred and the filesystem's auth flavor. Signed-off-by: Weston Andros Adamson <dros@netapp.com> --- Posting my proposed client-side fixes to follow the Security Considerations sections of the v4 and v4.1 specs wrt SECINFO. The question remains - if servers aren't supposed to return NFS4ERR_WRONGSEC, but only RECOMMENDED to use krb5i/p for SECINFO, how does a server tell the client that it doesn't support that auth flavor? Once we figure this out, I'll update the patch to retry in that case too. There will also be similar patches to SECINFO_NONAME and LAYOUTGET (which has a similiar regression, but doesn't have the no NFS4ERR_WRONGSEC limitation). fs/nfs/nfs4proc.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 47 insertions(+), 6 deletions(-)