From patchwork Tue Jul 2 01:04:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718797 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 112A1B64A for ; Tue, 2 Jul 2024 01:04:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882298; cv=none; b=ebuoTlH89jhHXfPLlxvPUi7JaKTUgbGxq++83ZWu3q8HhcXdt+Bxx/Sy3fwNpxwvHIj5nhTMEcnL72s+viZtXsGJOwSRDg49FQfxWJ+m4aVk0BOgxB792EZaYOWWOEEQC9jswZT8Pe08XAx1OQVkb0zNLYqwahW0L8YR84/4pXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882298; c=relaxed/simple; bh=ZYX7g0pqHnIDMnxzy2i3882fhMOxpdN1RRR3bwLflH0=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RHjLbCw+X0ykI+OiZM63RflMANqXAchDh2GDkc8cxQRQVClNn4VnVdUhnREyII7k1pl3ylep1Up+wH10/kSe4fDPKVAUPnU7wBBnFKp2gwgcCmqSRLioirdDPNWad+vq3DvXJQ1jTQfUXESF+xg9xpZ8NAsy0VmQM0wx3qXuNZg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aM1tFMeS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aM1tFMeS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2B5BC116B1; Tue, 2 Jul 2024 01:04:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882297; bh=ZYX7g0pqHnIDMnxzy2i3882fhMOxpdN1RRR3bwLflH0=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=aM1tFMeSgrND3h+OXeVIQSzlSIipNMkUVvCkgRe6xtSRkvOH3lPuJaWPrhUyoo6fl M96kH8JgSMnhbze+kyabyluT9GBBSVKMsKALeunH9LE+XDVgbVwgAsyYXOOgXd7ubz qpRoc9xAIQ7eeFRJ+RHWxG4ErWfrjfR+3N6YLKagAbt4BFbLzHia7Aqx7DqLgx3H/I PgUzfnW/H47V5TCmRtDGadPl0s8QeNXAWWiT4jCkWBdZ23LyrBajzxBAbtcjiNyHkk apdztNizc2mnBEZxN/xZYTqy06LmKYtW85FZxxv2V9ADk3hsxJuMJOk34S+zrCHkI2 mvHo1vBBq3wMA== Date: Mon, 01 Jul 2024 18:04:57 -0700 Subject: [PATCH 1/6] xfs_scrub: allow auxiliary pathnames for sandboxing From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119021.2008208.14026851256345116344.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong In the next patch, we'll tighten up the security on the xfs_scrub service so that it can't escape. However, sandboxing the service involves making the host filesystem as inaccessible as possible, with the filesystem to scrub bind mounted onto a known location within the sandbox. Hence we need one path for reporting and a new -M argument to tell scrub what it should actually be trying to open. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- man/man8/xfs_scrub.8 | 9 ++++++++- scrub/phase1.c | 4 ++-- scrub/vfs.c | 2 +- scrub/xfs_scrub.c | 11 ++++++++--- scrub/xfs_scrub.h | 5 ++++- 5 files changed, 23 insertions(+), 8 deletions(-) diff --git a/man/man8/xfs_scrub.8 b/man/man8/xfs_scrub.8 index b9f253e1b079..6154011271e6 100644 --- a/man/man8/xfs_scrub.8 +++ b/man/man8/xfs_scrub.8 @@ -4,7 +4,7 @@ xfs_scrub \- check and repair the contents of a mounted XFS filesystem .SH SYNOPSIS .B xfs_scrub [ -.B \-abCemnTvx +.B \-abCeMmnTvx ] .I mount-point .br @@ -79,6 +79,13 @@ behavior. .B \-k Do not call TRIM on the free space. .TP +.BI \-M " real-mount-point" +Open the this path for issuing scrub system calls to the kernel. +The positional +.I mount-point +parameter will be used for displaying informational messages and logging. +This parameter exists to enable process sandboxing for service mode. +.TP .BI \-m " file" Search this file for mounted filesystems instead of /etc/mtab. .TP diff --git a/scrub/phase1.c b/scrub/phase1.c index 1b3f6e8eb4f3..516d929d6268 100644 --- a/scrub/phase1.c +++ b/scrub/phase1.c @@ -146,7 +146,7 @@ phase1_func( * CAP_SYS_ADMIN, which we probably need to do anything fancy * with the (XFS driver) kernel. */ - error = -xfd_open(&ctx->mnt, ctx->mntpoint, + error = -xfd_open(&ctx->mnt, ctx->actual_mntpoint, O_RDONLY | O_NOATIME | O_DIRECTORY); if (error) { if (error == EPERM) @@ -199,7 +199,7 @@ _("Not an XFS filesystem.")); return error; } - error = path_to_fshandle(ctx->mntpoint, &ctx->fshandle, + error = path_to_fshandle(ctx->actual_mntpoint, &ctx->fshandle, &ctx->fshandle_len); if (error) { str_errno(ctx, _("getting fshandle")); diff --git a/scrub/vfs.c b/scrub/vfs.c index 22c19485a2da..fca9a4cf3568 100644 --- a/scrub/vfs.c +++ b/scrub/vfs.c @@ -249,7 +249,7 @@ scan_fs_tree( goto out_cond; } - ret = queue_subdir(ctx, &sft, &wq, ctx->mntpoint, true); + ret = queue_subdir(ctx, &sft, &wq, ctx->actual_mntpoint, true); if (ret) { str_liberror(ctx, ret, _("queueing directory scan")); goto out_wq; diff --git a/scrub/xfs_scrub.c b/scrub/xfs_scrub.c index 296d814eceeb..d7cef115deea 100644 --- a/scrub/xfs_scrub.c +++ b/scrub/xfs_scrub.c @@ -725,7 +725,7 @@ main( pthread_mutex_init(&ctx.lock, NULL); ctx.mode = SCRUB_MODE_REPAIR; ctx.error_action = ERRORS_CONTINUE; - while ((c = getopt(argc, argv, "a:bC:de:km:no:TvxV")) != EOF) { + while ((c = getopt(argc, argv, "a:bC:de:kM:m:no:TvxV")) != EOF) { switch (c) { case 'a': ctx.max_errors = cvt_u64(optarg, 10); @@ -769,6 +769,9 @@ main( case 'k': want_fstrim = false; break; + case 'M': + ctx.actual_mntpoint = optarg; + break; case 'm': mtab = optarg; break; @@ -823,6 +826,8 @@ main( usage(); ctx.mntpoint = argv[optind]; + if (!ctx.actual_mntpoint) + ctx.actual_mntpoint = ctx.mntpoint; stdout_isatty = isatty(STDOUT_FILENO); stderr_isatty = isatty(STDERR_FILENO); @@ -840,7 +845,7 @@ main( return SCRUB_RET_OPERROR; /* Find the mount record for the passed-in argument. */ - if (stat(argv[optind], &ctx.mnt_sb) < 0) { + if (stat(ctx.actual_mntpoint, &ctx.mnt_sb) < 0) { fprintf(stderr, _("%s: could not stat: %s: %s\n"), progname, argv[optind], strerror(errno)); @@ -863,7 +868,7 @@ main( } fs_table_initialise(0, NULL, 0, NULL); - fsp = fs_table_lookup_mount(ctx.mntpoint); + fsp = fs_table_lookup_mount(ctx.actual_mntpoint); if (!fsp) { fprintf(stderr, _("%s: Not a XFS mount point.\n"), ctx.mntpoint); diff --git a/scrub/xfs_scrub.h b/scrub/xfs_scrub.h index 7d48f4bad9ce..b0aa9fcc67b7 100644 --- a/scrub/xfs_scrub.h +++ b/scrub/xfs_scrub.h @@ -38,9 +38,12 @@ enum error_action { struct scrub_ctx { /* Immutable scrub state. */ - /* Strings we need for presentation */ + /* Mountpoint we use for presentation */ char *mntpoint; + /* Actual VFS path to the filesystem */ + char *actual_mntpoint; + /* Mountpoint info */ struct stat mnt_sb; struct statvfs mnt_sv; From patchwork Tue Jul 2 01:05:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718798 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7BBA2F46 for ; Tue, 2 Jul 2024 01:05:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882313; cv=none; b=B1a5DD6XxcJ0zPg1LC6GShA8wpFIQX4S0dpcWJEJ7qhPN1CjEmXNq7mKaApdQd68xZRnyWQvaOX2djcKHssHnBl08Wjb8TvuBPRDeqbEtqjj/0E+JvnjFv8Mh0IpJQabAPcZWB5i7IeoCK9fzISuitJFWjPmBcamdYQTnGy0WOs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882313; c=relaxed/simple; bh=yWMZ0LAO779jmvfwNT/un+V1b9ILdbRGI9TVW7T0M7U=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jntzfV4V/ob1v23XfBIqUkytVzNvPdfQRVoIkqI4875E/LJ67MTZgKu78g+mji37Hf14QMHtcSp2igodquhugbiGknGz5uIVrjZJJ7S0+3zbn3WdGRAGkoP0xrF57OWfeBNi41jwfNQ31QZT0X+HNLB24WL5wjX9cqX+Yq51OPQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b0LJmWlQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b0LJmWlQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DF2CC4AF0C; Tue, 2 Jul 2024 01:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882313; bh=yWMZ0LAO779jmvfwNT/un+V1b9ILdbRGI9TVW7T0M7U=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=b0LJmWlQE3dhY9CkYzwn7/VZUXYL7lcetKHfDZK8oXqX7JF2+7Hw7HuasTbDGfcdK a/022aknqPoTHhqkPrS9kHT6m52ghDZD5XvtX9RzmhMSEeWl4pCsoZbvBZNe9Bpmf1 s6MjcrQXpxzn59DEGTRVr+/HU4a8EelGKWbgzAe4BK/L3z2/czvOlcWa2U5lqxTZry T1kgBxDnHWGjR6U+TTNmgegK8NKe+VNs1XdeIvymSXTUmhNzHAZKvaCYuhCD74x5O4 /BRvTBjD/30EgAHXUjP2TUz+8tM5lTuUAdE6lEuOlZ0xjiNCJWvNXVYq80D8SAfPFR FlRvGQPSX+mtw== Date: Mon, 01 Jul 2024 18:05:13 -0700 Subject: [PATCH 2/6] xfs_scrub.service: reduce background CPU usage to less than one core if possible From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: Christoph Hellwig , linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119036.2008208.12375299031312294476.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Currently, the xfs_scrub background service is configured to use -b, which means that the program runs completely serially. However, even using all of one CPU core with idle priority may be enough to cause thermal throttling and unwanted fan noise on smaller systems (e.g. laptops) with fast IO systems. Let's try to avoid this (at least on systemd) by using cgroups to limit the program's usage to slghtly more than half of one CPU and lowering the nice priority in the scheduler. What we /really/ want is to run steadily on an efficiency core, but there doesn't seem to be a means to ask the scheduler not to ramp up the CPU frequency for a particular task. While we're at it, group the resource limit directives together. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- scrub/Makefile | 7 ++++++- scrub/system-xfs_scrub.slice | 30 ++++++++++++++++++++++++++++++ scrub/xfs_scrub@.service.in | 12 ++++++++++-- scrub/xfs_scrub_all.service.in | 4 ++++ scrub/xfs_scrub_fail@.service.in | 4 ++++ 5 files changed, 54 insertions(+), 3 deletions(-) create mode 100644 scrub/system-xfs_scrub.slice diff --git a/scrub/Makefile b/scrub/Makefile index 8ccc67d01df3..2a257e0805cd 100644 --- a/scrub/Makefile +++ b/scrub/Makefile @@ -18,7 +18,12 @@ XFS_SCRUB_FAIL_PROG = xfs_scrub_fail XFS_SCRUB_ARGS = -b -n ifeq ($(HAVE_SYSTEMD),yes) INSTALL_SCRUB += install-systemd -SYSTEMD_SERVICES = $(scrub_svcname) xfs_scrub_all.service xfs_scrub_all.timer xfs_scrub_fail@.service +SYSTEMD_SERVICES=\ + $(scrub_svcname) \ + xfs_scrub_fail@.service \ + xfs_scrub_all.service \ + xfs_scrub_all.timer \ + system-xfs_scrub.slice OPTIONAL_TARGETS += $(SYSTEMD_SERVICES) endif ifeq ($(HAVE_CROND),yes) diff --git a/scrub/system-xfs_scrub.slice b/scrub/system-xfs_scrub.slice new file mode 100644 index 000000000000..95cd4f74526f --- /dev/null +++ b/scrub/system-xfs_scrub.slice @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Copyright (c) 2022-2024 Oracle. All Rights Reserved. +# Author: Darrick J. Wong + +[Unit] +Description=xfs_scrub background service slice +Before=slices.target + +[Slice] + +# If the CPU usage cgroup controller is available, don't use more than 60% of a +# single core for all background processes. +CPUQuota=60% +CPUAccounting=true + +[Install] +# As of systemd 249, the systemd cgroupv2 configuration code will drop resource +# controllers from the root and system.slice cgroups at startup if it doesn't +# find any direct dependencies that require a given controller. Newly +# activated units with resource control directives are created under the system +# slice but do not cause a reconfiguration of the slice's resource controllers. +# Hence we cannot put CPUQuota= into the xfs_scrub service units directly. +# +# For the CPUQuota directive to have any effect, we must therefore create an +# explicit definition file for the slice that systemd creates to contain the +# xfs_scrub instance units (e.g. xfs_scrub@.service) and we must configure this +# slice as a dependency of the system slice to establish the direct dependency +# relation. +WantedBy=system.slice diff --git a/scrub/xfs_scrub@.service.in b/scrub/xfs_scrub@.service.in index 05e5293ee1ac..855fe4de4dcf 100644 --- a/scrub/xfs_scrub@.service.in +++ b/scrub/xfs_scrub@.service.in @@ -18,8 +18,16 @@ PrivateTmp=no AmbientCapabilities=CAP_SYS_ADMIN CAP_FOWNER CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SYS_RAWIO NoNewPrivileges=yes User=nobody -IOSchedulingClass=idle -CPUSchedulingPolicy=idle Environment=SERVICE_MODE=1 ExecStart=@sbindir@/xfs_scrub @scrub_args@ %f SyslogIdentifier=%N + +# Run scrub with minimal CPU and IO priority so that nothing else will starve. +IOSchedulingClass=idle +CPUSchedulingPolicy=idle +CPUAccounting=true +Nice=19 + +# Create the service underneath the scrub background service slice so that we +# can control resource usage. +Slice=system-xfs_scrub.slice diff --git a/scrub/xfs_scrub_all.service.in b/scrub/xfs_scrub_all.service.in index 347cd6e66228..96be90e74ee6 100644 --- a/scrub/xfs_scrub_all.service.in +++ b/scrub/xfs_scrub_all.service.in @@ -14,3 +14,7 @@ Type=oneshot Environment=SERVICE_MODE=1 ExecStart=@sbindir@/xfs_scrub_all SyslogIdentifier=xfs_scrub_all + +# Create the service underneath the scrub background service slice so that we +# can control resource usage. +Slice=system-xfs_scrub.slice diff --git a/scrub/xfs_scrub_fail@.service.in b/scrub/xfs_scrub_fail@.service.in index 96a2ed5da31e..32012ec35366 100644 --- a/scrub/xfs_scrub_fail@.service.in +++ b/scrub/xfs_scrub_fail@.service.in @@ -14,3 +14,7 @@ ExecStart=@pkg_libexec_dir@/xfs_scrub_fail "${EMAIL_ADDR}" %f User=mail Group=mail SupplementaryGroups=systemd-journal + +# Create the service underneath the scrub background service slice so that we +# can control resource usage. +Slice=system-xfs_scrub.slice From patchwork Tue Jul 2 01:05:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718799 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D9E82F46 for ; Tue, 2 Jul 2024 01:05:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882329; cv=none; b=OyhG65gkXrY510HpBdUFjvIjQ8aQop0nq5o6tfimiqG2Dwb2rToNPdR+HL51A+U5MVGERXij/G8Dz8o3Xv9Jvc8YrhKAYpbDTNHC+AfKpBOaGB4m1Uq/0pdydsAxiCWY0L3F1x5hz5S7SEGEORj3KgO8VRYMszmKG3jKamJauPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882329; c=relaxed/simple; bh=Of3j2r1F36e+kiPZYoRGazJvgseSIVUWoE6TO8uS1qs=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KT/+3xoAnYxXjJNIR8oL7czV2adiLGlpE4UJl6FPXHIVJnh2d7jp0Lc0zS/ZiV+MqYs7Qo2BVQvWH3afptHfAN9HO858bb238rKQRzkx1y4OV+GWa67nlpapFJIs0yUdefocZJpg+l7BGxvWY4xwo+1UqulCobVf1oRN590/G2I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J2RV6fv1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="J2RV6fv1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EBC4C116B1; Tue, 2 Jul 2024 01:05:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882329; bh=Of3j2r1F36e+kiPZYoRGazJvgseSIVUWoE6TO8uS1qs=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=J2RV6fv1X+KWjGUSk+GVOjqahaqmCG92qz7mcw07UmxFW2U5WBtl9SqgCBhddbs+A uLDSp25saoRYjEN+Q77g911gj8PfBqNYpjrAfm00/wIXV6vwR2wSk/jCmf/4wU67HO 5cixw5frlPC/QgyV2ipjE9OEAZZtxALaCIrM7yHeYqI4fZc3AuGkhu/pAGq4TadbO7 xsgI7bNo7kM7IF/Mnp3khY4rAGSepsFNWZsgb2BslACqqD7EZ70wfSmZfuilraKgzw zvY4YszHZwcDWwCZxKtw3KP+V8ZWNLFHAcGkdAIWJu5Zgj4W7OITfeF2Pkj0kHAdg+ 6Tz8Ofouhg2Dg== Date: Mon, 01 Jul 2024 18:05:28 -0700 Subject: [PATCH 3/6] xfs_scrub: use dynamic users when running as a systemd service From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: Helle Vaanzinn , Christoph Hellwig , linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119051.2008208.10956893253250060106.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Five years ago, systemd introduced the DynamicUser directive that allocates a new unique user/group id, runs a service with those ids, and deletes them after the service exits. This is a good replacement for User=nobody, since it eliminates the threat of nobody-services messing with each other. Make this transition ahead of all the other security tightenings that will land in the next few patches, and add credits for the people who suggested the change and reviewed it. Link: https://0pointer.net/blog/dynamic-users-with-systemd.html Suggested-by: Helle Vaanzinn Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong --- scrub/xfs_scrub@.service.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scrub/xfs_scrub@.service.in b/scrub/xfs_scrub@.service.in index 855fe4de4dcf..52068add834d 100644 --- a/scrub/xfs_scrub@.service.in +++ b/scrub/xfs_scrub@.service.in @@ -17,7 +17,6 @@ ProtectHome=read-only PrivateTmp=no AmbientCapabilities=CAP_SYS_ADMIN CAP_FOWNER CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SYS_RAWIO NoNewPrivileges=yes -User=nobody Environment=SERVICE_MODE=1 ExecStart=@sbindir@/xfs_scrub @scrub_args@ %f SyslogIdentifier=%N @@ -31,3 +30,6 @@ Nice=19 # Create the service underneath the scrub background service slice so that we # can control resource usage. Slice=system-xfs_scrub.slice + +# Dynamically create a user that isn't root +DynamicUser=true From patchwork Tue Jul 2 01:05:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718800 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15AF44A06 for ; Tue, 2 Jul 2024 01:05:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882345; cv=none; b=bNxlPey9qim9Ns0BjWoO13a2qb1H5X0Glb094BRoYg/X9Lenqwz3gXjTHU8G7A2W78IxQpCO/qYmZ6QcN8Hrs4vkOshhTfJctK5K/Cbl4K4CV7cEGwY3d9nBSL4JVqf4/SafnM00BFUTgHm9dPitQG2U7KyG5kBn/fz77Zo0rRo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882345; c=relaxed/simple; bh=Ki/m6hbBw5WA3SFG0UiJ4oWE+fecQhitDqih3j1v8SI=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LlROCcdylr4Dylyu1EgwoqHdY3BLZEJHWe52qUTrJvu/yoVNZ10urmJ7VNvE/zxBkb3JTOby6dBW3J6ELulK9nxvc9HI1fmo6qnnwMezkw4PAHxBKVbuBz7EyyN/Omo081eI7oxnA0j/LAiSPjgqcyTszyfWW2fPMxo8rkptqNw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fjqzK0SH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fjqzK0SH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC502C116B1; Tue, 2 Jul 2024 01:05:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882344; bh=Ki/m6hbBw5WA3SFG0UiJ4oWE+fecQhitDqih3j1v8SI=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=fjqzK0SHsARVP3i1yXFt9sM6XHVRbWCD66K+UaT1IyTqbQL0jx9kuvwiX7uuq/xi5 dIUxhmAEgSxxIYAmOYR0aq6rcPuj9SzFgAD03MQwJp9mblNrOrToMB+OLI7pswBCD9 Ol6uE27uLlxeuvv7+KtCzXr1iAtAc8Kt5AqegSiEpNoqTSkvd7KiACGIyDgCrbXPtt VcVCgJ7Ua+AJneGeieC3NL7f9DizdpS9LhRTgUIgN5Mb98s2Y2p06VVcyilLbnN8qW kYtUusHX/n6WoJWcMtOGuw7ejr4YH2TOixS1wudpX5MX7GV5Q+3sDtbsuiMt+6xI2K bJq9yiZ67Zn/Q== Date: Mon, 01 Jul 2024 18:05:44 -0700 Subject: [PATCH 4/6] xfs_scrub: tighten up the security on the background systemd service From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: Christoph Hellwig , linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119067.2008208.15565100581130657110.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Currently, xfs_scrub has to run with some elevated privileges. Minimize the risk of xfs_scrub escaping its service container or contaminating the rest of the system by using systemd's sandboxing controls to prohibit as much access as possible. The directives added by this patch were recommended by the command 'systemd-analyze security xfs_scrub@.service' in systemd 249. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- scrub/xfs_scrub@.service.in | 81 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 8 deletions(-) diff --git a/scrub/xfs_scrub@.service.in b/scrub/xfs_scrub@.service.in index 52068add834d..a8dd9052f0e0 100644 --- a/scrub/xfs_scrub@.service.in +++ b/scrub/xfs_scrub@.service.in @@ -8,17 +8,21 @@ Description=Online XFS Metadata Check for %f OnFailure=xfs_scrub_fail@%i.service Documentation=man:xfs_scrub(8) +# Explicitly require the capabilities that this program needs +ConditionCapability=CAP_SYS_ADMIN +ConditionCapability=CAP_FOWNER +ConditionCapability=CAP_DAC_OVERRIDE +ConditionCapability=CAP_DAC_READ_SEARCH +ConditionCapability=CAP_SYS_RAWIO + +# Must be a mountpoint +ConditionPathIsMountPoint=%f +RequiresMountsFor=%f + [Service] Type=oneshot -PrivateNetwork=true -ProtectSystem=full -ProtectHome=read-only -# Disable private /tmp just in case %f is a path under /tmp. -PrivateTmp=no -AmbientCapabilities=CAP_SYS_ADMIN CAP_FOWNER CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SYS_RAWIO -NoNewPrivileges=yes Environment=SERVICE_MODE=1 -ExecStart=@sbindir@/xfs_scrub @scrub_args@ %f +ExecStart=@sbindir@/xfs_scrub @scrub_args@ -M /tmp/scrub/ %f SyslogIdentifier=%N # Run scrub with minimal CPU and IO priority so that nothing else will starve. @@ -31,5 +35,66 @@ Nice=19 # can control resource usage. Slice=system-xfs_scrub.slice +# No realtime CPU scheduling +RestrictRealtime=true + # Dynamically create a user that isn't root DynamicUser=true + +# Make the entire filesystem readonly and /home inaccessible, then bind mount +# the filesystem we're supposed to be checking into our private /tmp dir. +# 'norbind' means that we don't bind anything under that original mount. +ProtectSystem=strict +ProtectHome=yes +PrivateTmp=true +BindPaths=%f:/tmp/scrub:norbind + +# Don't let scrub complain about paths in /etc/projects that have been hidden +# by our sandboxing. scrub doesn't care about project ids anyway. +InaccessiblePaths=-/etc/projects + +# No network access +PrivateNetwork=true +ProtectHostname=true +RestrictAddressFamilies=none +IPAddressDeny=any + +# Don't let the program mess with the kernel configuration at all +ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +ProtectControlGroups=true +ProtectProc=invisible +RestrictNamespaces=true + +# Hide everything in /proc, even /proc/mounts +ProcSubset=pid + +# Only allow the default personality Linux +LockPersonality=true + +# No writable memory pages +MemoryDenyWriteExecute=true + +# Don't let our mounts leak out to the host +PrivateMounts=true + +# Restrict system calls to the native arch and only enough to get things going +SystemCallArchitectures=native +SystemCallFilter=@system-service +SystemCallFilter=~@privileged +SystemCallFilter=~@resources +SystemCallFilter=~@mount + +# xfs_scrub needs these privileges to run, and no others +CapabilityBoundingSet=CAP_SYS_ADMIN CAP_FOWNER CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SYS_RAWIO +AmbientCapabilities=CAP_SYS_ADMIN CAP_FOWNER CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SYS_RAWIO +NoNewPrivileges=true + +# xfs_scrub doesn't create files +UMask=7777 + +# No access to hardware /dev files except for block devices +ProtectClock=true +DevicePolicy=closed +DeviceAllow=block-* From patchwork Tue Jul 2 01:06:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718801 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8E206FCB for ; Tue, 2 Jul 2024 01:06:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882360; cv=none; b=P1dNjbwfz2qXW5ljiLykv2Gz6DktdZHzW06olHrgDQC6E6b6qH2HNcLPwE/9zb32XRH8BnO0awP+m7aMSMDogiim5HsFknve472uf5LnzSWM6r5wT7XPt9FIRU14bvby6i7NtGcSW5YVskKBXtpY3Buaqr0/jyhcZBga/0cQSGY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882360; c=relaxed/simple; bh=x4eutwcjUDCv9hEzlUvjhvuK9PmVDMz0xpRVOLRV4Uc=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fZO5e7+LYg4hQvuCyPnOAhuidUoU0fY/C3G4Tqnxsr6Fv4Woi0SimTYosiIXj1Rv4tawP+4/Qsq00Ntr0VtRp9H9GiTde3PZjmHDxzWAN4ZwOjMfvq8AJeFk0ffCdaKu33iHz4K1WUFUC0WgCHhk71IN0kVln7DS+HZCxV1+DuU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QD34tzOy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QD34tzOy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80BA2C116B1; Tue, 2 Jul 2024 01:06:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882360; bh=x4eutwcjUDCv9hEzlUvjhvuK9PmVDMz0xpRVOLRV4Uc=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=QD34tzOyVbggmr8QsW1fZrPg01D1d6+nbQfzoaRVjWUskKiIIEQn9Bjis09JmpXiY z90ndH3JptBPuGXjQnfvkSyhpmagOOFB2oBL7slxSSKAEQzXeXILKXn9Mk0O4zRiXH XYX9Mscsop7KtkrWGYgpFt54kQ6VuK5vm4c3bRO6vl4mYD7LDtIfoxaYZZHKmT2TLg gnrjichHnlUjAN2TM5t0YiQG8dbUNeawhl7qMg4GepReTPNc6oW/h5OMEkZNd3TwF2 LaQRXPSsudKZm+oy0jo2KJefyzz9OdXApXzvXe5TIDsfb2sQOY24Nl4hK0lypnpuN6 usun/TM8arRIQ== Date: Mon, 01 Jul 2024 18:06:00 -0700 Subject: [PATCH 5/6] xfs_scrub_fail: tighten up the security on the background systemd service From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119082.2008208.12273526437995077384.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Currently, xfs_scrub_fail has to run with enough privileges to access the journal contents for a given scrub run and to send a report via email. Minimize the risk of xfs_scrub_fail escaping its service container or contaminating the rest of the system by using systemd's sandboxing controls to prohibit as much access as possible. The directives added by this patch were recommended by the command 'systemd-analyze security xfs_scrub_fail@.service' in systemd 249. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- scrub/xfs_scrub_fail@.service.in | 55 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/scrub/xfs_scrub_fail@.service.in b/scrub/xfs_scrub_fail@.service.in index 32012ec35366..2c879afd6d8e 100644 --- a/scrub/xfs_scrub_fail@.service.in +++ b/scrub/xfs_scrub_fail@.service.in @@ -18,3 +18,58 @@ SupplementaryGroups=systemd-journal # Create the service underneath the scrub background service slice so that we # can control resource usage. Slice=system-xfs_scrub.slice + +# No realtime scheduling +RestrictRealtime=true + +# Make the entire filesystem readonly and /home inaccessible. +ProtectSystem=full +ProtectHome=yes +PrivateTmp=true +RestrictSUIDSGID=true + +# Emailing reports requires network access, but not the ability to change the +# hostname. +ProtectHostname=true + +# Don't let the program mess with the kernel configuration at all +ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +ProtectControlGroups=true +ProtectProc=invisible +RestrictNamespaces=true + +# Can't hide /proc because journalctl needs it to find various pieces of log +# information +#ProcSubset=pid + +# Only allow the default personality Linux +LockPersonality=true + +# No writable memory pages +MemoryDenyWriteExecute=true + +# Don't let our mounts leak out to the host +PrivateMounts=true + +# Restrict system calls to the native arch and only enough to get things going +SystemCallArchitectures=native +SystemCallFilter=@system-service +SystemCallFilter=~@privileged +SystemCallFilter=~@resources +SystemCallFilter=~@mount + +# xfs_scrub needs these privileges to run, and no others +CapabilityBoundingSet= +NoNewPrivileges=true + +# Failure reporting shouldn't create world-readable files +UMask=0077 + +# Clean up any IPC objects when this unit stops +RemoveIPC=true + +# No access to hardware device files +PrivateDevices=true +ProtectClock=true From patchwork Tue Jul 2 01:06:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13718802 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D04F79CC for ; Tue, 2 Jul 2024 01:06:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882376; cv=none; b=rmnjQwR75QI1cfZGZZf8D86MzlXiWs779zLvwZqTz/tCTCZb1e/KA+68vurWhw/LuaBOhctLWslU2UEVEZQr3pgy2FfLuzaS8ZIW5N39EK8sMfSvUPrka+vAfj1ZHCay5SAwH3CZI8XfOVdhRzSajhx+erVWWLix70x5msLRhhg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719882376; c=relaxed/simple; bh=RVXQhExL0prrk+NCxWMc2eTLUuEcaMpYH6p7JAFGxZc=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kwhjYT2ulSxoFjOyNBzAQi+vOUKJ4HiSOJq9o4jbIJP/E6STxoskT9Pish+ZVfUWsFnWMUoEcz83CCFhVcixoRex+qcF/n0UMqHxyYwDr6Rx2buGS5iaGX5Gnm6S+hn/+4ELqTZ1YWZhptzru84nm+S06HoKxc5RlcF3aBdLTKA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tkp2YTqL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tkp2YTqL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 248B0C116B1; Tue, 2 Jul 2024 01:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719882376; bh=RVXQhExL0prrk+NCxWMc2eTLUuEcaMpYH6p7JAFGxZc=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=tkp2YTqLO4iISpp/jJSDt0qGp96U6+KtmiSd6Mwtfx7jKINOVoEYjdppAHTSP8qfB dP6ojzIQ0PSYk6QNSx0RK4wSS4U2kcuyOqquVGDdDkJ8nUm2PTRCO6bZiKE9RosZv6 1MiRpPT+JD/P1dFA9W3yB2tdbwCe1iYmLsq1E9eeHj3xfZ/aTkA6Ya+kyL43exdLJT v2eiQoDcN8eGf6GFhqp5saMC3VDOzIg2nyGX5IU7I+vHwnKtIpLbkYRW5+hhJPXy9J 4UruuX64ri6YFwaSHf+DK4a0BeiGgJbd3GXXug+dze5xPNfA68hpUbUxsjp2dKjbXx axTMsg9iGXOuA== Date: Mon, 01 Jul 2024 18:06:15 -0700 Subject: [PATCH 6/6] xfs_scrub_all: tighten up the security on the background systemd service From: "Darrick J. Wong" To: djwong@kernel.org, cem@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <171988119097.2008208.5897497587818401006.stgit@frogsfrogsfrogs> In-Reply-To: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> References: <171988118996.2008208.13502268616736256245.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Currently, xfs_scrub_all has to run with enough privileges to find mounted XFS filesystems and the device associated with that mount and to start xfs_scrub@ sub-services. Minimize the risk of xfs_scrub_all escaping its service container or contaminating the rest of the system by using systemd's sandboxing controls to prohibit as much access as possible. The directives added by this patch were recommended by the command 'systemd-analyze security xfs_scrub_all.service' in systemd 249. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- scrub/xfs_scrub_all.service.in | 62 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/scrub/xfs_scrub_all.service.in b/scrub/xfs_scrub_all.service.in index 96be90e74ee6..478cd8d057a2 100644 --- a/scrub/xfs_scrub_all.service.in +++ b/scrub/xfs_scrub_all.service.in @@ -18,3 +18,65 @@ SyslogIdentifier=xfs_scrub_all # Create the service underneath the scrub background service slice so that we # can control resource usage. Slice=system-xfs_scrub.slice + +# Run scrub_all with minimal CPU and IO priority so that nothing will starve. +IOSchedulingClass=idle +CPUSchedulingPolicy=idle +CPUAccounting=true +Nice=19 + +# No realtime scheduling +RestrictRealtime=true + +# No special privileges, but we still have to run as root so that we can +# contact the service manager to start the sub-units. +CapabilityBoundingSet= +NoNewPrivileges=true +RestrictSUIDSGID=true + +# Make the entire filesystem readonly. We don't want to hide anything because +# we need to find all mounted XFS filesystems in the host. +ProtectSystem=strict +ProtectHome=read-only +PrivateTmp=false + +# No network access except to the systemd control socket +PrivateNetwork=true +ProtectHostname=true +RestrictAddressFamilies=AF_UNIX +IPAddressDeny=any + +# Don't let the program mess with the kernel configuration at all +ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +ProtectControlGroups=true +ProtectProc=invisible +RestrictNamespaces=true + +# Hide everything in /proc, even /proc/mounts +ProcSubset=pid + +# Only allow the default personality Linux +LockPersonality=true + +# No writable memory pages +MemoryDenyWriteExecute=true + +# Don't let our mounts leak out to the host +PrivateMounts=true + +# Restrict system calls to the native arch and only enough to get things going +SystemCallArchitectures=native +SystemCallFilter=@system-service +SystemCallFilter=~@privileged +SystemCallFilter=~@resources +SystemCallFilter=~@mount + +# Media scan stamp file shouldn't be readable by regular users +UMask=0077 + +# lsblk ignores mountpoints if it can't find the device files, so we cannot +# hide them +#ProtectClock=true +#PrivateDevices=true