diff mbox

NFSv4: use the mach cred for SECINFO w/ integrity

Message ID 1378235929-4710-1-git-send-email-dros@netapp.com (mailing list archive)
State New, archived
Headers show

Commit Message

Weston Andros Adamson Sept. 3, 2013, 7:18 p.m. UTC
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(-)

Comments

Trond Myklebust Sept. 3, 2013, 7:25 p.m. UTC | #1
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
Adamson, Dros Sept. 3, 2013, 7:30 p.m. UTC | #2
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
Adamson, Dros Sept. 3, 2013, 7:32 p.m. UTC | #3
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
Trond Myklebust Sept. 3, 2013, 7:39 p.m. UTC | #4
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
Chuck Lever III Sept. 3, 2013, 7:40 p.m. UTC | #5
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?
Adamson, Dros Sept. 3, 2013, 7:45 p.m. UTC | #6
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
Trond Myklebust Sept. 3, 2013, 7:52 p.m. UTC | #7
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
Adamson, Dros Sept. 3, 2013, 7:55 p.m. UTC | #8
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
Trond Myklebust Sept. 3, 2013, 7:59 p.m. UTC | #9
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 mbox

Patch

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);