From patchwork Sat Jan 7 14:45:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kinglong Mee X-Patchwork-Id: 9503083 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 0E23E606DE for ; Sat, 7 Jan 2017 14:46:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DFB4428419 for ; Sat, 7 Jan 2017 14:46:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C14CF28462; Sat, 7 Jan 2017 14:46:42 +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_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, 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 518C728419 for ; Sat, 7 Jan 2017 14:46:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751607AbdAGOql (ORCPT ); Sat, 7 Jan 2017 09:46:41 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:33513 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751306AbdAGOqk (ORCPT ); Sat, 7 Jan 2017 09:46:40 -0500 Received: by mail-pg0-f66.google.com with SMTP id 194so2466055pgd.0 for ; Sat, 07 Jan 2017 06:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=kbHO7e7MJbvXTqxlbpJHQJ993EzzX3q8Kkslk3pwcU4=; b=fpDtclVxXaazuOpp+Pb5tX/3TPcITy1TEwaC3PmE5f+n2YHJY3yEfj7CRhv6pJr6s4 ZXtn99weTPpwHSRhEDbK/Y2t4Hhe8QcseI3yOp/LJtGX559FfuwW9XWWeCc9nkgF3nEJ sNd15fWl5YkxIB+IcGDZIGkgdJeNGD9UTVA7vmFe0v0Ti1drMl7TgxwiQmqGP3bJ/uG4 ctQUQ/CS5TjFqY/3NwGUnfZ1cjLmU+tk7bkPoVD43eOvxCDZemAGveR3RPEs+mSl50iX z7xIFlmo0soZrCxRLvQ5YOkv2KVSqMDGUnQCRTccq89jkNlmY+q19ZTB8fuNfEjTNRrs 3iwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=kbHO7e7MJbvXTqxlbpJHQJ993EzzX3q8Kkslk3pwcU4=; b=t2xePxs5rDteUL7oPcZdlHipsFKj41VsKH+apPAKovpTD0ZKNiGTRorHmvBdR5nQUe b+FEfMNHkUPUlT7E3/oV/VPLlAxLzSV4LOB5a4SWd3ETHqHSY4j7djq90A9aN+IZQptn VzMUNYAagar3qTfHurs0PBUdx1F08LxjKx1VDxttV6V1C6NMxDpEOlhmhGi50sX3unp/ Kd4+C87R2uCK9quOmzT7E87LMqWo/RdTGpcOhW6p0gdcJtK7wpsabc66Af9Ep1fMZjMJ ardzZckXTDuGCwYPRVVbKdKNGTR76Pqf72c1VWiJHYXjIeQR1h1/O70cfr4WwJk6viqU KOrg== X-Gm-Message-State: AIkVDXI2I9hdAUzfiFmmfhaJ5+Lii1f55qzgfOVQyOPKIE8vt2Q7Qwlf2D7+aCRiUtU+YQ== X-Received: by 10.84.202.12 with SMTP id w12mr179873963pld.156.1483800399613; Sat, 07 Jan 2017 06:46:39 -0800 (PST) Received: from [192.168.0.106] ([183.228.31.151]) by smtp.googlemail.com with ESMTPSA id f23sm166730337pff.59.2017.01.07.06.46.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Jan 2017 06:46:39 -0800 (PST) To: Trond Myklebust , linux-nfs@vger.kernel.org Cc: Andreas Gruenbacher , kinglongmee@gmail.com, Matthieu Herrb From: Kinglong Mee Subject: [PATCH] NFSv4.2: Fix file creating with O_EXCL get a bad mode Message-ID: Date: Sat, 7 Jan 2017 22:45:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 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 Acorrding to Matthieu Herrb's test cases, a new created file will get a bad mode as 0666 (expected 0644) after commit dff25ddb4808 "nfs: add support for the umask attribute". It is caused by missing check of FATTR4_WORD2_MODE_UMASK in nfs4_exclusive_attrset. #include #include #include #include #include #include #include #include /* * Demonstrate file creation bug on NFS v4 and linux kernel 4.4+ * * mktemp() is used on purpose. */ int main(int argc, char *argv[]) { const char *name = argv[1]; char tmp[] = "./tmpXXXXXXXXXX"; struct stat buf; mode_t expected; int fd, i, n = 40; umask(S_IWGRP | S_IWOTH); expected = 0666 & ~(S_IWGRP | S_IWOTH); if (argv[1] == NULL) name = mktemp(tmp); for (i = 0; i < n; i++) { fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0666); if (fd < 0) err(1, "open %s", name); memset(&buf, 0, sizeof(buf)); if (stat(name, &buf) < 0) err(1, "stat %s", name); if ((buf.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != expected) printf("%s: %o\n", name, (int)buf.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)); else printf("%s: ok\n", name); unlink(name); } exit(0); } Signed-off-by: Kinglong Mee --- fs/nfs/nfs4proc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 6dcbc5d..a3e9ef1 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -2697,7 +2697,8 @@ static inline void nfs4_exclusive_attrset(struct nfs4_opendata *opendata, sattr->ia_valid |= ATTR_MTIME; /* Except MODE, it seems harmless of setting twice. */ - if ((attrset[1] & FATTR4_WORD1_MODE)) + if ((attrset[1] & FATTR4_WORD1_MODE) || + (attrset[2] & FATTR4_WORD2_MODE_UMASK)) sattr->ia_valid &= ~ATTR_MODE; if (attrset[2] & FATTR4_WORD2_SECURITY_LABEL)