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@xxxxxxxxxx>
> ---
Thanks! Applied...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
