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 <[email protected]>
---
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(-)
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);
--
1.7.12.4 (Apple Git-37)
On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <[email protected]> wrote:
> On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote:
>> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <[email protected]>
>> 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 <[email protected]>
>>>> ---
>>>
>>> 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?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Sep 3, 2013, at 3:30 PM, "Adamson, Dros" <[email protected]>
wrote:
>
> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <[email protected]>
> 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 <[email protected]>
>>> ---
>>
>> 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
>> [email protected]
>> http://www.netapp.com
>
T24gVHVlLCAyMDEzLTA5LTAzIGF0IDE1OjE4IC0wNDAwLCBXZXN0b24gQW5kcm9zIEFkYW1zb24g
d3JvdGU6DQo+IENvbW1pdCA1ZWMxNmE4NTAwZDMzOWIwZTdhMGNjNzZiNzg1ZDE4ZGFhZDM1NGQ0
IGludHJvZHVjZWQgYSByZWdyZXNzaW9uDQo+IHRoYXQgY2F1c2VzIFNFQ0lORk8gdG8gZmFpbCB3
aXRob3V0IGFjdHVhbHkgc2VuZGluZyBhbiBSUEMgaWY6DQo+IA0KPiAgMSkgdGhlIG5mc19jbGll
bnQncyBycGNfY2xpZW50IHdhcyB1c2luZyBLUkI1aS9wIChub3cgdHJpZWQgYnkgZGVmYXVsdCkN
Cj4gIDIpIHRoZSBjdXJyZW50IHVzZXIgZG9lc24ndCBoYXZlIHZhbGlkIGtlcmJlcm9zIGNyZWRl
bnRpYWxzDQo+IA0KPiBUaGlzIHNpdHVhdGlvbiBpcyBxdWl0ZSBjb21tb24gLSBhcyBvZiBub3cg
YSBzZWM9c3lzIG1vdW50IHdvdWxkIHVzZQ0KPiBrcmI1aSBmb3IgdGhlIG5mc19jbGllbnQncyBy
cGNfY2xpZW50IGFuZCBhIHVzZXIgd291bGQgaGFyZGx5IGJlIGZhdWx0ZWQNCj4gZm9yIG5vdCBo
YXZpbmcgcnVuIGtpbml0Lg0KPiANCj4gVGhlIHNvbHV0aW9uIGlzIHRvIHVzZSB0aGUgbWFjaGlu
ZSBjcmVkIHdoZW4gdHJ5aW5nIHRvIHVzZSBhbiBpbnRlZ3JpdHkNCj4gcHJvdGVjdGVkIGF1dGgg
Zmxhdm9yIGZvciBTRUNJTkZPLg0KPiANCj4gT2xkZXIgc2VydmVycyBtYXkgbm90IHN1cHBvcnQg
dXNpbmcgdGhlIG1hY2hpbmUgY3JlZCBvciBhbiBpbnRlZ3JpdHkNCj4gcHJvdGVjdGVkIGF1dGgg
Zmxhdm9yIGZvciBTRUNJTkZPIGluIGV2ZXJ5IGNpcmN1bXN0YW5jZSwgc28gd2UgZmFsbCBiYWNr
DQo+IHRvIHVzaW5nIHRoZSB1c2VyJ3MgY3JlZCBhbmQgdGhlIGZpbGVzeXN0ZW0ncyBhdXRoIGZs
YXZvciBpbiB0aGlzIGNhc2UuDQo+IA0KPiBXZSBydW4gaW50byBhbm90aGVyIHByb2JsZW0gd2hl
biBydW5uaW5nIGFnYWluc3QgbGludXggbmZzIHNlcnZlcnMgLQ0KPiB0aGV5IHJldHVybiBORlM0
RVJSX1dST05HU0VDIHdoZW4gdXNpbmcgaW50ZWdyaXR5IGF1dGggZmxhdm9yICh1bmxlc3MgdGhl
DQo+IG1vdW50IGlzIGFsc28gdGhhdCBmbGF2b3IpIGV2ZW4gdGhvdWdoIHRoYXQgaXMgbm90IGEg
dmFsaWQgZXJyb3IgZm9yDQo+IFNFQ0lORk8qLiAgRXZlbiB0aG91Z2ggaXQncyBhZ2FpbnN0IHNw
ZWMsIGhhbmRsZSBXUk9OR1NFQyBlcnJvcnMgb24gU0VDSU5GTw0KPiBieSBmYWxsaW5nIGJhY2sg
dG8gdXNpbmcgdGhlIHVzZXIgY3JlZCBhbmQgdGhlIGZpbGVzeXN0ZW0ncyBhdXRoIGZsYXZvci4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IFdlc3RvbiBBbmRyb3MgQWRhbXNvbiA8ZHJvc0BuZXRhcHAu
Y29tPg0KPiAtLS0NCg0KVGhhbmtzISBBcHBsaWVkLi4uDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0
DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RA
bmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg==
T24gVHVlLCAyMDEzLTA5LTAzIGF0IDE5OjMwICswMDAwLCBBZGFtc29uLCBEcm9zIHdyb3RlOg0K
PiBPbiBTZXAgMywgMjAxMywgYXQgMzoyNSBQTSwgIk15a2xlYnVzdCwgVHJvbmQiIDxUcm9uZC5N
eWtsZWJ1c3RAbmV0YXBwLmNvbT4NCj4gIHdyb3RlOg0KPiANCj4gPiBPbiBUdWUsIDIwMTMtMDkt
MDMgYXQgMTU6MTggLTA0MDAsIFdlc3RvbiBBbmRyb3MgQWRhbXNvbiB3cm90ZToNCj4gPj4gQ29t
bWl0IDVlYzE2YTg1MDBkMzM5YjBlN2EwY2M3NmI3ODVkMThkYWFkMzU0ZDQgaW50cm9kdWNlZCBh
IHJlZ3Jlc3Npb24NCj4gPj4gdGhhdCBjYXVzZXMgU0VDSU5GTyB0byBmYWlsIHdpdGhvdXQgYWN0
dWFseSBzZW5kaW5nIGFuIFJQQyBpZjoNCj4gPj4gDQo+ID4+IDEpIHRoZSBuZnNfY2xpZW50J3Mg
cnBjX2NsaWVudCB3YXMgdXNpbmcgS1JCNWkvcCAobm93IHRyaWVkIGJ5IGRlZmF1bHQpDQo+ID4+
IDIpIHRoZSBjdXJyZW50IHVzZXIgZG9lc24ndCBoYXZlIHZhbGlkIGtlcmJlcm9zIGNyZWRlbnRp
YWxzDQo+ID4+IA0KPiA+PiBUaGlzIHNpdHVhdGlvbiBpcyBxdWl0ZSBjb21tb24gLSBhcyBvZiBu
b3cgYSBzZWM9c3lzIG1vdW50IHdvdWxkIHVzZQ0KPiA+PiBrcmI1aSBmb3IgdGhlIG5mc19jbGll
bnQncyBycGNfY2xpZW50IGFuZCBhIHVzZXIgd291bGQgaGFyZGx5IGJlIGZhdWx0ZWQNCj4gPj4g
Zm9yIG5vdCBoYXZpbmcgcnVuIGtpbml0Lg0KPiA+PiANCj4gPj4gVGhlIHNvbHV0aW9uIGlzIHRv
IHVzZSB0aGUgbWFjaGluZSBjcmVkIHdoZW4gdHJ5aW5nIHRvIHVzZSBhbiBpbnRlZ3JpdHkNCj4g
Pj4gcHJvdGVjdGVkIGF1dGggZmxhdm9yIGZvciBTRUNJTkZPLg0KPiA+PiANCj4gPj4gT2xkZXIg
c2VydmVycyBtYXkgbm90IHN1cHBvcnQgdXNpbmcgdGhlIG1hY2hpbmUgY3JlZCBvciBhbiBpbnRl
Z3JpdHkNCj4gPj4gcHJvdGVjdGVkIGF1dGggZmxhdm9yIGZvciBTRUNJTkZPIGluIGV2ZXJ5IGNp
cmN1bXN0YW5jZSwgc28gd2UgZmFsbCBiYWNrDQo+ID4+IHRvIHVzaW5nIHRoZSB1c2VyJ3MgY3Jl
ZCBhbmQgdGhlIGZpbGVzeXN0ZW0ncyBhdXRoIGZsYXZvciBpbiB0aGlzIGNhc2UuDQo+ID4+IA0K
PiA+PiBXZSBydW4gaW50byBhbm90aGVyIHByb2JsZW0gd2hlbiBydW5uaW5nIGFnYWluc3QgbGlu
dXggbmZzIHNlcnZlcnMgLQ0KPiA+PiB0aGV5IHJldHVybiBORlM0RVJSX1dST05HU0VDIHdoZW4g
dXNpbmcgaW50ZWdyaXR5IGF1dGggZmxhdm9yICh1bmxlc3MgdGhlDQo+ID4+IG1vdW50IGlzIGFs
c28gdGhhdCBmbGF2b3IpIGV2ZW4gdGhvdWdoIHRoYXQgaXMgbm90IGEgdmFsaWQgZXJyb3IgZm9y
DQo+ID4+IFNFQ0lORk8qLiAgRXZlbiB0aG91Z2ggaXQncyBhZ2FpbnN0IHNwZWMsIGhhbmRsZSBX
Uk9OR1NFQyBlcnJvcnMgb24gU0VDSU5GTw0KPiA+PiBieSBmYWxsaW5nIGJhY2sgdG8gdXNpbmcg
dGhlIHVzZXIgY3JlZCBhbmQgdGhlIGZpbGVzeXN0ZW0ncyBhdXRoIGZsYXZvci4NCj4gPj4gDQo+
ID4+IFNpZ25lZC1vZmYtYnk6IFdlc3RvbiBBbmRyb3MgQWRhbXNvbiA8ZHJvc0BuZXRhcHAuY29t
Pg0KPiA+PiAtLS0NCj4gPiANCj4gPiBUaGFua3MhIEFwcGxpZWTigKYNCj4gDQo+IE9oLCBzb3Jy
eSwgSSB3YXMgaG9waW5nIHRvIGZvc3RlciBtb3JlIGRpc2N1c3Npb24gYXJvdW5kIENodWNrJ3Mg
Y29tbWVudHMgdG8gdGhlIG5mc2Qgc2lkZSBvZiB0aGlzIGVmZm9ydCBiZWZvcmUgYWRkaW5nIHRo
aXMsIGFsdGhvdWdoIGl0J3MgYmV0dGVyIHRoYW4gdGhlIHN0YXRlIHRoZSBjbGllbnQgd2FzIGlu
IHNpbmNlIDVlYzE2YTg1MDBkMzM5YjBlN2EwY2M3NmI3ODVkMThkYWFkMzU0ZDQuICBTaG91bGQg
SSBwb3N0IHRoZSBzaW1pbGFyIHBhdGNoZXMgZm9yIFNFQ0lORk9fTk9OQU1FIGFuZCBMQVlPVVRH
RVQ/DQo+IA0KPiBTcGVjaWZpY2FsbHksIENodWNrJ3MgKHZlcnkgdmFsaWQpIHBvaW50IGlzIHdo
YXQgZXJyb3Igc2hvdWxkIGEgc2VydmVyIHJldHVybiB0byBTRUNJTkZPIHVzaW5nIGtyYjVpIGlm
IGl0IGRvZXNuJ3Qgc3VwcG9ydCB0aGF0IGF1dGggZmxhdm9yPyAgIA0KPiBORlM0RVJSX0FDQ0VT
UyBsb29rcyBsaWtlIHRoZSBiZXN0IGF2YWlsYWJsZSBvcHRpb24gdG8gbWUgLS0gc2hvdWxkIEkg
dGFrZSB0aGlzIHRvIHRoZSBJRVRGIGxpc3Q/DQoNCklmIHRoZSBzZXJ2ZXIgZG9lc24ndCBzdXBw
b3J0IGtyYjVpLCB0aGVuIGl0IHdvbid0IGV2ZW4gYmUgYWJsZSB0bw0KcmVjZWl2ZSBvdXIgUlBD
IGNhbGwsIHNvIGl0IGNhbiBhdCBiZXN0IHJlcGx5IHdpdGggYW4gQVVUSF9CQURDUkVEIHJwYw0K
bGV2ZWwgZXJyb3IsIHdoaWNoIHJwY192ZXJpZnlfaGVhZGVyKCkgd2lsbCB0cmFuc2xhdGUgYXMg
RUFDQ0VTLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFp
bmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29t
DQo=
On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <[email protected]> wrote:
> On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote:
>> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <[email protected]>
>> 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 <[email protected]>
>>>> ---
>>>
>>> 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
> [email protected]
> http://www.netapp.com
On Sep 3, 2013, at 3:52 PM, "Myklebust, Trond" <[email protected]> wrote:
> On Tue, 2013-09-03 at 15:40 -0400, Chuck Lever wrote:
>> On Sep 3, 2013, at 3:39 PM, "Myklebust, Trond" <[email protected]> wrote:
>>
>>> On Tue, 2013-09-03 at 19:30 +0000, Adamson, Dros wrote:
>>>> On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <[email protected]>
>>>> 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 <[email protected]>
>>>>>> ---
>>>>>
>>>>> 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
> [email protected]
> http://www.netapp.com
T24gVHVlLCAyMDEzLTA5LTAzIGF0IDE5OjU1ICswMDAwLCBBZGFtc29uLCBEcm9zIHdyb3RlOg0K
PiBPbiBTZXAgMywgMjAxMywgYXQgMzo1MiBQTSwgIk15a2xlYnVzdCwgVHJvbmQiIDxUcm9uZC5N
eWtsZWJ1c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+IA0KPiA+IE9uIFR1ZSwgMjAxMy0wOS0wMyBh
dCAxNTo0MCAtMDQwMCwgQ2h1Y2sgTGV2ZXIgd3JvdGU6DQo+ID4+IE9uIFNlcCAzLCAyMDEzLCBh
dCAzOjM5IFBNLCAiTXlrbGVidXN0LCBUcm9uZCIgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29t
PiB3cm90ZToNCj4gPj4gDQo+ID4+PiBPbiBUdWUsIDIwMTMtMDktMDMgYXQgMTk6MzAgKzAwMDAs
IEFkYW1zb24sIERyb3Mgd3JvdGU6DQo+ID4+Pj4gT24gU2VwIDMsIDIwMTMsIGF0IDM6MjUgUE0s
ICJNeWtsZWJ1c3QsIFRyb25kIiA8VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+DQo+ID4+Pj4g
d3JvdGU6DQo+ID4+Pj4gDQo+ID4+Pj4+IE9uIFR1ZSwgMjAxMy0wOS0wMyBhdCAxNToxOCAtMDQw
MCwgV2VzdG9uIEFuZHJvcyBBZGFtc29uIHdyb3RlOg0KPiA+Pj4+Pj4gQ29tbWl0IDVlYzE2YTg1
MDBkMzM5YjBlN2EwY2M3NmI3ODVkMThkYWFkMzU0ZDQgaW50cm9kdWNlZCBhIHJlZ3Jlc3Npb24N
Cj4gPj4+Pj4+IHRoYXQgY2F1c2VzIFNFQ0lORk8gdG8gZmFpbCB3aXRob3V0IGFjdHVhbHkgc2Vu
ZGluZyBhbiBSUEMgaWY6DQo+ID4+Pj4+PiANCj4gPj4+Pj4+IDEpIHRoZSBuZnNfY2xpZW50J3Mg
cnBjX2NsaWVudCB3YXMgdXNpbmcgS1JCNWkvcCAobm93IHRyaWVkIGJ5IGRlZmF1bHQpDQo+ID4+
Pj4+PiAyKSB0aGUgY3VycmVudCB1c2VyIGRvZXNuJ3QgaGF2ZSB2YWxpZCBrZXJiZXJvcyBjcmVk
ZW50aWFscw0KPiA+Pj4+Pj4gDQo+ID4+Pj4+PiBUaGlzIHNpdHVhdGlvbiBpcyBxdWl0ZSBjb21t
b24gLSBhcyBvZiBub3cgYSBzZWM9c3lzIG1vdW50IHdvdWxkIHVzZQ0KPiA+Pj4+Pj4ga3JiNWkg
Zm9yIHRoZSBuZnNfY2xpZW50J3MgcnBjX2NsaWVudCBhbmQgYSB1c2VyIHdvdWxkIGhhcmRseSBi
ZSBmYXVsdGVkDQo+ID4+Pj4+PiBmb3Igbm90IGhhdmluZyBydW4ga2luaXQuDQo+ID4+Pj4+PiAN
Cj4gPj4+Pj4+IFRoZSBzb2x1dGlvbiBpcyB0byB1c2UgdGhlIG1hY2hpbmUgY3JlZCB3aGVuIHRy
eWluZyB0byB1c2UgYW4gaW50ZWdyaXR5DQo+ID4+Pj4+PiBwcm90ZWN0ZWQgYXV0aCBmbGF2b3Ig
Zm9yIFNFQ0lORk8uDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IE9sZGVyIHNlcnZlcnMgbWF5IG5vdCBz
dXBwb3J0IHVzaW5nIHRoZSBtYWNoaW5lIGNyZWQgb3IgYW4gaW50ZWdyaXR5DQo+ID4+Pj4+PiBw
cm90ZWN0ZWQgYXV0aCBmbGF2b3IgZm9yIFNFQ0lORk8gaW4gZXZlcnkgY2lyY3Vtc3RhbmNlLCBz
byB3ZSBmYWxsIGJhY2sNCj4gPj4+Pj4+IHRvIHVzaW5nIHRoZSB1c2VyJ3MgY3JlZCBhbmQgdGhl
IGZpbGVzeXN0ZW0ncyBhdXRoIGZsYXZvciBpbiB0aGlzIGNhc2UuDQo+ID4+Pj4+PiANCj4gPj4+
Pj4+IFdlIHJ1biBpbnRvIGFub3RoZXIgcHJvYmxlbSB3aGVuIHJ1bm5pbmcgYWdhaW5zdCBsaW51
eCBuZnMgc2VydmVycyAtDQo+ID4+Pj4+PiB0aGV5IHJldHVybiBORlM0RVJSX1dST05HU0VDIHdo
ZW4gdXNpbmcgaW50ZWdyaXR5IGF1dGggZmxhdm9yICh1bmxlc3MgdGhlDQo+ID4+Pj4+PiBtb3Vu
dCBpcyBhbHNvIHRoYXQgZmxhdm9yKSBldmVuIHRob3VnaCB0aGF0IGlzIG5vdCBhIHZhbGlkIGVy
cm9yIGZvcg0KPiA+Pj4+Pj4gU0VDSU5GTyouICBFdmVuIHRob3VnaCBpdCdzIGFnYWluc3Qgc3Bl
YywgaGFuZGxlIFdST05HU0VDIGVycm9ycyBvbiBTRUNJTkZPDQo+ID4+Pj4+PiBieSBmYWxsaW5n
IGJhY2sgdG8gdXNpbmcgdGhlIHVzZXIgY3JlZCBhbmQgdGhlIGZpbGVzeXN0ZW0ncyBhdXRoIGZs
YXZvci4NCj4gPj4+Pj4+IA0KPiA+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogV2VzdG9uIEFuZHJvcyBB
ZGFtc29uIDxkcm9zQG5ldGFwcC5jb20+DQo+ID4+Pj4+PiAtLS0NCj4gPj4+Pj4gDQo+ID4+Pj4+
IFRoYW5rcyEgQXBwbGllZOKApg0KPiA+Pj4+IA0KPiA+Pj4+IE9oLCBzb3JyeSwgSSB3YXMgaG9w
aW5nIHRvIGZvc3RlciBtb3JlIGRpc2N1c3Npb24gYXJvdW5kIENodWNrJ3MgY29tbWVudHMgdG8g
dGhlIG5mc2Qgc2lkZSBvZiB0aGlzIGVmZm9ydCBiZWZvcmUgYWRkaW5nIHRoaXMsIGFsdGhvdWdo
IGl0J3MgYmV0dGVyIHRoYW4gdGhlIHN0YXRlIHRoZSBjbGllbnQgd2FzIGluIHNpbmNlIDVlYzE2
YTg1MDBkMzM5YjBlN2EwY2M3NmI3ODVkMThkYWFkMzU0ZDQuICBTaG91bGQgSSBwb3N0IHRoZSBz
aW1pbGFyIHBhdGNoZXMgZm9yIFNFQ0lORk9fTk9OQU1FIGFuZCBMQVlPVVRHRVQ/DQo+ID4+Pj4g
DQo+ID4+Pj4gU3BlY2lmaWNhbGx5LCBDaHVjaydzICh2ZXJ5IHZhbGlkKSBwb2ludCBpcyB3aGF0
IGVycm9yIHNob3VsZCBhIHNlcnZlciByZXR1cm4gdG8gU0VDSU5GTyB1c2luZyBrcmI1aSBpZiBp
dCBkb2Vzbid0IHN1cHBvcnQgdGhhdCBhdXRoIGZsYXZvcj8gICANCj4gPj4+PiBORlM0RVJSX0FD
Q0VTUyBsb29rcyBsaWtlIHRoZSBiZXN0IGF2YWlsYWJsZSBvcHRpb24gdG8gbWUgLS0gc2hvdWxk
IEkgdGFrZSB0aGlzIHRvIHRoZSBJRVRGIGxpc3Q/DQo+ID4+PiANCj4gPj4+IElmIHRoZSBzZXJ2
ZXIgZG9lc24ndCBzdXBwb3J0IGtyYjVpLCB0aGVuIGl0IHdvbid0IGV2ZW4gYmUgYWJsZSB0bw0K
PiA+Pj4gcmVjZWl2ZSBvdXIgUlBDIGNhbGwsIHNvIGl0IGNhbiBhdCBiZXN0IHJlcGx5IHdpdGgg
YW4gQVVUSF9CQURDUkVEIHJwYw0KPiA+Pj4gbGV2ZWwgZXJyb3IsIHdoaWNoIHJwY192ZXJpZnlf
aGVhZGVyKCkgd2lsbCB0cmFuc2xhdGUgYXMgRUFDQ0VTLg0KPiA+PiANCj4gPj4gV2hhdCBpZiB0
aGUgc2VydmVyIHN1cHBvcnRzIFJQQ1NFQ19HU1MsIGJ1dCB0aGUgZXhwb3J0IG9wdGlvbnMgc3Bl
Y2lmeSBvbmx5IHNlYz1zeXM/DQo+ID4gDQo+ID4gUkZDNTY2MSBzcGVjaWZpY2FsbHkgc3RhdGVz
IHRoYXQgaXQgc2hvdWxkIGFjY2VwdCB0aGUgU0VDSU5GTyBjYWxsIHdpdGgNCj4gPiBSUENTRUNf
R1NTIGluIHRoYXQgY2FzZS4NCj4gPiANCj4gPiBSRkMzNTMwYmlzIGRvZXMgdG9vLCBidXQgdGhl
cmUgbWF5IGJlIGEgbGVnYWN5IFJGQzM1MzAgaXNzdWUgdGhlcmUuDQo+IA0KPiBJIGd1ZXNzIGFz
IGZhciBhcyB0aGlzIHBhdGNoIChhbmQgZm9ydGhjb21pbmcgU0VDSU5GT19OT05BTUUpIGdvZXMs
IGRvIHdlIHdhbnQgdG8gcmV0cnkgKGZhbGxpbmcgYmFjayB0byB1c2VyIGNyZWQpIG9uIE5GUzRF
UlJfQUNDRVNTIHRvbz8NCg0KU0VDSU5GT19OT19OQU1FIGlzIGNvdmVyZWQgYnkgUkZDNTY2MSwg
c28gdGhlcmUgc2hvdWxkIGJlIG5vIGxlZ2FjeQ0KcHJvYmxlbXMgKG9ubHkgc2VydmVyIGJ1Z3Mp
LiBUaGUgY3VycmVudCBjb2RlIHNob3VsZCB0aGVyZWZvcmUgYmUNCmNvcnJlY3Qgd2l0aG91dCBh
bnkgbmVlZCBmb3IgY2hhbmdlcy4NCg0KVGhlIG9ubHkgcG90ZW50aWFsIHByb2JsZW0gaXMgU0VD
SU5GTyBpdHNlbGYgZm9yIHRoZSBORlN2NC4wIGNhc2UuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0
DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RA
bmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg==
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
On Sep 3, 2013, at 3:25 PM, "Myklebust, Trond" <[email protected]>
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 <[email protected]>
>> ---
>
> 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
> [email protected]
> http://www.netapp.com