diff mbox

changing error message for mount failure

Message ID CAN-5tyGWFYp-dU=8Prpmyyr=B=Z3jAfiO_qs0-KfC_xvDwUMaA@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Olga Kornievskaia Feb. 21, 2017, 9:43 p.m. UTC 
In the upstream kernel when doing the mount without specifying the
security flavor and the server returning EACCES to the
PUTROOTFH|GETATTR, the code ends up translating this to EPERM which
mount fails with "Operation not permitted". Doing the same mount, but
specifying "sec=sys" on the command line translates to the "Access
denied" error. While not too terrible, it's just a bit inconsistent.

Anna pointed me to this discussion
https://lists.gt.net/linux/kernel/1366207#1366207 that was possibly
the reason for the translation of EACCES to EPERM in
nfs4_find_root_sec().

Is this still a needed correction? I tried: no gssd running and asking
for a krb5 mount and it leads to "an incorrect mount option was
specified" (EINVAL returned by nfs).

I propose to remove it to address the difference in error messages for EACCES:
--
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

Comments

Olga Kornievskaia March 2, 2017, 7:44 p.m. UTC | #1 
On Tue, Feb 21, 2017 at 4:43 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> In the upstream kernel when doing the mount without specifying the
> security flavor and the server returning EACCES to the
> PUTROOTFH|GETATTR, the code ends up translating this to EPERM which
> mount fails with "Operation not permitted". Doing the same mount, but
> specifying "sec=sys" on the command line translates to the "Access
> denied" error. While not too terrible, it's just a bit inconsistent.
>
> Anna pointed me to this discussion
> https://lists.gt.net/linux/kernel/1366207#1366207 that was possibly
> the reason for the translation of EACCES to EPERM in
> nfs4_find_root_sec().
>
> Is this still a needed correction? I tried: no gssd running and asking
> for a krb5 mount and it leads to "an incorrect mount option was
> specified" (EINVAL returned by nfs).
>
> I propose to remove it to address the difference in error messages for EACCES:
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index d293f06..a03f587 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -3576,15 +3576,6 @@ static int nfs4_find_root_sec(struct nfs_server
> *server, struct nfs_fh *fhandle,
>   }
>   }
>
> - /*
> - * -EACCESS could mean that the user doesn't have correct permissions
> - * to access the mount.  It could also mean that we tried to mount
> - * with a gss auth flavor, but rpc.gssd isn't running.  Either way,
> - * existing mount programs don't handle -EACCES very well so it should
> - * be mapped to -EPERM instead.
> - */
> - if (status == -EACCES)
> - status = -EPERM;
>   return status;
>  }

Any comments about the suggested change would be appreciated.
--
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
diff mbox

Patch

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index d293f06..a03f587 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3576,15 +3576,6 @@  static int nfs4_find_root_sec(struct nfs_server
*server, struct nfs_fh *fhandle,
  }
  }

- /*
- * -EACCESS could mean that the user doesn't have correct permissions
- * to access the mount.  It could also mean that we tried to mount
- * with a gss auth flavor, but rpc.gssd isn't running.  Either way,
- * existing mount programs don't handle -EACCES very well so it should
- * be mapped to -EPERM instead.
- */
- if (status == -EACCES)
- status = -EPERM;
  return status;
 }