From patchwork Tue Feb 21 21:43:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Olga Kornievskaia X-Patchwork-Id: 9585791 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 75A8360578 for ; Tue, 21 Feb 2017 21:43:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5CB0528620 for ; Tue, 21 Feb 2017 21:43:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5177F28644; Tue, 21 Feb 2017 21:43:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 487182862D for ; Tue, 21 Feb 2017 21:43:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751271AbdBUVnh (ORCPT ); Tue, 21 Feb 2017 16:43:37 -0500 Received: from mail-it0-f45.google.com ([209.85.214.45]:36347 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752443AbdBUVnb (ORCPT ); Tue, 21 Feb 2017 16:43:31 -0500 Received: by mail-it0-f45.google.com with SMTP id h10so119329360ith.1 for ; Tue, 21 Feb 2017 13:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=QVXmIOMsGUNE1KPVJ8cWKPZqTHVFmsF6flRKUnZA86g=; b=rwCzmquPy6+FQPOK/mgQ+dK3kB0yt6dDobPUW0AJG6DIARbxBicJHDgBRHgSDcVwIp HugaKM10WPxEFx0SJxqpGTDxYqq4zaKLiP+z3p498/WsRh05abSCRIxE3esS33Ya2Xv3 yQI9zgVpB2y2GVMKzDEqy8nO6KCoIjuwP/37cVzBpOEZ0/6L4uiEeG1TRovYawBI6e9W Tgdb9Yq/Yil0seFXFUbJFDxZePO/rbEJtLH+hdygQhua59LKT66rM/zxOsPvz/uKme1j gXEZ+wbRS6ssEfh2yeTvpKGwT7l6h0J0geYNNb1KY8s9d+QqmcO7iRF5F3ifioWqm4ME g7Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=QVXmIOMsGUNE1KPVJ8cWKPZqTHVFmsF6flRKUnZA86g=; b=C1KwaLV1etuIalwVmUUniRQph2XPZgti2gPDUOMZlfOD2GmBWRiO9i1oGVCipSUMu3 o8zTEWbwb39SJpbSxHczNrtFRjfzfXXkMTFmbnesZrmiEZyW3p+HN8BfVtR9qbbQ9lFA 2tcAscpLQ8Cm/djTVZ7NFvZC9R8nW7Eox6HsfV92cQ/l5tshr1wb+XW40i7sbGY3vA4O V5h4nmrqpT0PAxlJvTyx+8KzOSFDbUStTR0fINzwOE7Yuy8upjCxQ7Y/jxA7j+3g24c0 8hMzhyW1S+k+qsPMJ+05dzVsE+zzotDL0f0q4OZ2vgBrIX7bMcWoqWm7A4FLi71mZX37 KZ4w== X-Gm-Message-State: AMke39mZqkWM6UgWpwNOQG3Hgzlg0VVjN89fgTGJ6wN4StR7YjQq+fcVy/bUu/KhlA8BV+KV2zI51A8N0F3cOw== X-Received: by 10.36.51.68 with SMTP id k65mr29503947itk.64.1487713410333; Tue, 21 Feb 2017 13:43:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.6.212 with HTTP; Tue, 21 Feb 2017 13:43:29 -0800 (PST) From: Olga Kornievskaia Date: Tue, 21 Feb 2017 16:43:29 -0500 X-Google-Sender-Auth: vk8yutlpe4j4SyjVgJBLivmC8r0 Message-ID: Subject: changing error message for mount failure To: linux-nfs Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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; }