From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC33BC4338F for ; Tue, 24 Aug 2021 17:27:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B105461360 for ; Tue, 24 Aug 2021 17:27:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240138AbhHXR2f (ORCPT ); Tue, 24 Aug 2021 13:28:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:60516 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240579AbhHXR0B (ORCPT ); Tue, 24 Aug 2021 13:26:01 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4107361B40; Tue, 24 Aug 2021 17:04:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629824649; bh=m1pPNIiaceAVvaCV/dm5OIIOUeAfNMp+1YyVr1mrmIk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XpEa9l7Ld+wpNGVe/rgeKUO63O7QuoZ6tGWp/DMPNB3C/WCWMr2u48aHc7oePfa7x GPiXqLtPj7o2+vQtQHYhQWnWnKgGVg+MzYwg4GtmLoQCudkQs/8kXJSM4dLvI6sKau TkerGR6JgpRybtJjgzWGvfLJAA19w8Oo/Z8meIfJ69XDqgCUCfk4n0FYMq0CmY3/jO BFQHrNqnQYDyFzuSISz5C27kPL257tIen37JZG3WzjMvQKhhHvHJA7pKMO1xJz6dCp IHVrj9sLtMJ4987AbvBN0nrqxbMTImM4lQdNA51jp8JjotZfBT4X4XsSakkrJNlvF1 Y5iBNhzEAATgA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jeff Layton , Jan Kara , Sasha Levin Subject: [PATCH 4.19 81/84] locks: print a warning when mount fails due to lack of "mand" support Date: Tue, 24 Aug 2021 13:02:47 -0400 Message-Id: <20210824170250.710392-82-sashal@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210824170250.710392-1-sashal@kernel.org> References: <20210824170250.710392-1-sashal@kernel.org> MIME-Version: 1.0 X-KernelTest-Patch: http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.205-rc1.gz X-KernelTest-Tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git X-KernelTest-Branch: linux-4.19.y X-KernelTest-Patches: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git X-KernelTest-Version: 4.19.205-rc1 X-KernelTest-Deadline: 2021-08-26T17:02+00:00 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jeff Layton [ Upstream commit df2474a22c42ce419b67067c52d71da06c385501 ] Since 9e8925b67a ("locks: Allow disabling mandatory locking at compile time"), attempts to mount filesystems with "-o mand" will fail. Unfortunately, there is no other indiciation of the reason for the failure. Change how the function is defined for better readability. When CONFIG_MANDATORY_FILE_LOCKING is disabled, printk a warning when someone attempts to mount with -o mand. Also, add a blurb to the mandatory-locking.txt file to explain about the "mand" option, and the behavior one should expect when it is disabled. Reported-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Jeff Layton Signed-off-by: Sasha Levin --- Documentation/filesystems/mandatory-locking.txt | 10 ++++++++++ fs/namespace.c | 11 ++++++++--- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/mandatory-locking.txt b/Documentation/filesystems/mandatory-locking.txt index 0979d1d2ca8b..a251ca33164a 100644 --- a/Documentation/filesystems/mandatory-locking.txt +++ b/Documentation/filesystems/mandatory-locking.txt @@ -169,3 +169,13 @@ havoc if they lock crucial files. The way around it is to change the file permissions (remove the setgid bit) before trying to read or write to it. Of course, that might be a bit tricky if the system is hung :-( +7. The "mand" mount option +-------------------------- +Mandatory locking is disabled on all filesystems by default, and must be +administratively enabled by mounting with "-o mand". That mount option +is only allowed if the mounting task has the CAP_SYS_ADMIN capability. + +Since kernel v4.5, it is possible to disable mandatory locking +altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel +with this disabled will reject attempts to mount filesystems with the +"mand" mount option with the error status EPERM. diff --git a/fs/namespace.c b/fs/namespace.c index edd397fa2991..8d2bf350e7c6 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1610,13 +1610,18 @@ static inline bool may_mount(void) return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN); } +#ifdef CONFIG_MANDATORY_FILE_LOCKING static inline bool may_mandlock(void) { -#ifndef CONFIG_MANDATORY_FILE_LOCKING - return false; -#endif return capable(CAP_SYS_ADMIN); } +#else +static inline bool may_mandlock(void) +{ + pr_warn("VFS: \"mand\" mount option not supported"); + return false; +} +#endif /* * Now umount can handle mount points as well as block devices. -- 2.30.2