From patchwork Tue Apr 8 15:40:02 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 14043204 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 C1BE61862BB for ; Tue, 8 Apr 2025 15:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126819; cv=none; b=KzyHxr4nL9CpJU+v3BHnvbdg4D41IcScsji7XNNjiL0pgETyS8adztycEDmCbKT3wkFCQyA3rDk1j64AJ5t5oQcDIqM3lR9FnImyY4YJUWrdAL6wvptkh9S2fjdR7WAYWnxp4y4ucrNnu08S6yC3ydWPM3hsICyp4VFu7asfZ/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126819; c=relaxed/simple; bh=1shebuS/I8nfl+A8U/rqE5CB+Bo+kQaPVbYV4UrP2ds=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GJqD9yOh+F7royRC0cJvnVCETeOmtF3ejwARKbaL5H7vZ33K00asMjI3OFzgiuKCy0Q57GtnIT6XptO8pc+YpJlA4uXKKUZ9UEom7LYrVkX3VQPkFMWsuwp4OOD5xYe/M/bVKH9R0WXue+kTl5s0LwUUyEJSAqzbC4PWM8w+/Ns= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HikNtb5Z; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HikNtb5Z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744126816; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rU8555WnOzv750rqynKzUgdgvOm7EFlOP9S2jBeJHFk=; b=HikNtb5ZczNs1CUKWz4dqZMzQr8y2QErK/GtjYhK0weEZ75giAua3U/8lgKGqtWfGrbYvK KuFL5WG6bjvwX4y9yE1SiOrmfDU+BOmQ4TndV1QJGt73CePQwVzD14wN34vzdcv17NMfrj vCpFKDYceQLqkrwbLCVi5I+YOKvDPJE= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-w8athDFTPaqMbGhGeCW-lg-1; Tue, 08 Apr 2025 11:40:15 -0400 X-MC-Unique: w8athDFTPaqMbGhGeCW-lg-1 X-Mimecast-MFC-AGG-ID: w8athDFTPaqMbGhGeCW-lg_1744126814 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-ac2aa3513ccso482782366b.0 for ; Tue, 08 Apr 2025 08:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744126814; x=1744731614; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rU8555WnOzv750rqynKzUgdgvOm7EFlOP9S2jBeJHFk=; b=uyTm9M4mne3OspMhCUIBI4GB8Bd74JKjulrKFM5dZxPxnGrRxlKSaOzegfWgf9gF7h B+QLlxwta7+0Pu0T6BzNRnmJK2m9qr3hxOktKupQ9jLlvEUIaBWic8wNdPx20tcK912+ oNtFXdXwxDvpIDa0x7bMmkxW7uF6raCuYayIqkcr33l1oSRodMoq/WfiyZa+J/932PJG 96Mzk+msfI3l1qQ86oBOVCxKzhQMetyk4qFOSh4lXCpumf426oy5LI2LomnpqYsoW0WF 5vrqbAOr+bi1b2fZ57cD0qPlPeiVq+klcS2EIXPFHLI0FOf1CTlypAgm7x90I5Zk9Zk6 cE6A== X-Forwarded-Encrypted: i=1; AJvYcCUT99VBNueAXQ8hoedAENGHyX/96IwpOvbcEZ+bO2HU3GtWG3tEIAJN70JHGXj9kjfzdkD7jGkayS7cYaJH@vger.kernel.org X-Gm-Message-State: AOJu0YzeTOcOB/z9j/Flp+SBbfnV5cwuDH5/YvsWYszbF8ksNq4U+QN9 0lIC+VahbbsblFvv5IZdKFNohL8IKfTV3jLoSWn/BbOWjo9Br7tbc2kKgjFPO4FF/lgNcfdabeh AuFuKqKsW6J/uD+FWgcs0yHJXwYUzSF5B+tPrH70J7VYnOOUj7liS/9nlbbfE4C4= X-Gm-Gg: ASbGncv1P/XXvgSbpyfOUFuEoEVZRE9HTT36D1ep30JJJmmsft1Zky5wJZQCLW45EXK P+f+0pqynj/H+zhIbDQiMvC3G6+mE3LpZ10gKu3TlN77JtJa7sZn3Td1B2qi1h1dXhUWawOzhWu psjKcBf0e32ZP0DU6uTOY7dZyqi1LbIB6FoQsvN7TX59Hl+8TYxgDCxf0o1fD3qxc3/toGDsbyI 7s6U8qqlBpUMwFhW9flVtgjb6+t7sUJlrFNBHmhEHyLO20+b2qHKlkDS3Y+QCnR66ZNHZhqDb/0 YkmhsiFyRwHRkoSYbtQcZTX0nSh+HR7aPj2pHOQ9uOXOdniH0bHEC9O6rsvO/x+wVSvOAuj9 X-Received: by 2002:a17:907:7f0b:b0:abf:fb78:673a with SMTP id a640c23a62f3a-ac7e72e01aamr1500405366b.29.1744126814148; Tue, 08 Apr 2025 08:40:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGWxeAIbybuLCoyKlplBW3tR5GZppFnRO0zdv3nkxn3JB0iJTR4sxrdGMa3XEZWrPfA10vK6g== X-Received: by 2002:a17:907:7f0b:b0:abf:fb78:673a with SMTP id a640c23a62f3a-ac7e72e01aamr1500403366b.29.1744126813782; Tue, 08 Apr 2025 08:40:13 -0700 (PDT) Received: from maszat.piliscsaba.szeredi.hu (193-226-212-63.pool.digikabel.hu. [193.226.212.63]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c01bb793sm927553766b.161.2025.04.08.08.40.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 08:40:13 -0700 (PDT) From: Miklos Szeredi To: linux-unionfs@vger.kernel.org Cc: Amir Goldstein , linux-fsdevel@vger.kernel.org, Giuseppe Scrivano , Alexander Larsson Subject: [PATCH v3 1/3] ovl: make redirect/metacopy rejection consistent Date: Tue, 8 Apr 2025 17:40:02 +0200 Message-ID: <20250408154011.673891-2-mszeredi@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408154011.673891-1-mszeredi@redhat.com> References: <20250408154011.673891-1-mszeredi@redhat.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 When overlayfs finds a file with metacopy and/or redirect attributes and the metacopy and/or redirect features are not enabled, then it refuses to act on those attributes while also issuing a warning. There was an inconsistency in not checking metacopy found from the index. And also only warning on an upper metacopy if it found the next file on the lower layer, while always warning for metacopy found on a lower layer. Fix these inconsistencies and make the logic more straightforward, paving the way for following patches to change when dataredirects are allowed. Signed-off-by: Miklos Szeredi --- fs/overlayfs/namei.c | 81 +++++++++++++++++++++++++++++++------------- 1 file changed, 57 insertions(+), 24 deletions(-) diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index be5c65d6f848..5cebdd05ab3a 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -16,6 +16,7 @@ struct ovl_lookup_data { struct super_block *sb; + struct dentry *dentry; const struct ovl_layer *layer; struct qstr name; bool is_dir; @@ -23,6 +24,8 @@ struct ovl_lookup_data { bool xwhiteouts; bool stop; bool last; + bool nextredirect; + bool nextmetacopy; char *redirect; int metacopy; /* Referring to last redirect xattr */ @@ -1024,6 +1027,31 @@ int ovl_verify_lowerdata(struct dentry *dentry) return ovl_maybe_validate_verity(dentry); } +/* + * Following redirects/metacopy can have security consequences: it's like a + * symlink into the lower layer without the permission checks. + * + * This is only a problem if the upper layer is untrusted (e.g comes from an USB + * drive). This can allow a non-readable file or directory to become readable. + * + * Only following redirects when redirects are enabled disables this attack + * vector when not necessary. + */ +static bool ovl_check_nextredirect(struct ovl_lookup_data *d) +{ + struct ovl_fs *ofs = OVL_FS(d->sb); + + if (d->nextmetacopy && !ofs->config.metacopy) { + pr_warn_ratelimited("refusing to follow metacopy origin for (%pd2)\n", d->dentry); + return false; + } + if (d->nextredirect && !ovl_redirect_follow(ofs)) { + pr_warn_ratelimited("refusing to follow redirect for (%pd2)\n", d->dentry); + return false; + } + return true; +} + struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, unsigned int flags) { @@ -1047,6 +1075,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, int metacopy_size = 0; struct ovl_lookup_data d = { .sb = dentry->d_sb, + .dentry = dentry, .name = dentry->d_name, .is_dir = false, .opaque = false, @@ -1054,6 +1083,8 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, .last = ovl_redirect_follow(ofs) ? false : !ovl_numlower(poe), .redirect = NULL, .metacopy = 0, + .nextredirect = false, + .nextmetacopy = false, }; if (dentry->d_name.len > ofs->namelen) @@ -1087,8 +1118,10 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, if (err) goto out_put_upper; - if (d.metacopy) + if (d.metacopy) { uppermetacopy = true; + d.nextmetacopy = true; + } metacopy_size = d.metacopy; } @@ -1099,6 +1132,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, goto out_put_upper; if (d.redirect[0] == '/') poe = roe; + d.nextredirect = true; } upperopaque = d.opaque; } @@ -1113,6 +1147,11 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, for (i = 0; !d.stop && i < ovl_numlower(poe); i++) { struct ovl_path lower = ovl_lowerstack(poe)[i]; + if (!ovl_check_nextredirect(&d)) { + err = -EPERM; + goto out_put; + } + if (!ovl_redirect_follow(ofs)) d.last = i == ovl_numlower(poe) - 1; else if (d.is_dir || !ofs->numdatalayer) @@ -1126,12 +1165,8 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, if (!this) continue; - if ((uppermetacopy || d.metacopy) && !ofs->config.metacopy) { - dput(this); - err = -EPERM; - pr_warn_ratelimited("refusing to follow metacopy origin for (%pd2)\n", dentry); - goto out_put; - } + if (d.metacopy) + d.nextmetacopy = true; /* * If no origin fh is stored in upper of a merge dir, store fh @@ -1185,22 +1220,8 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, ctr++; } - /* - * Following redirects can have security consequences: it's like - * a symlink into the lower layer without the permission checks. - * This is only a problem if the upper layer is untrusted (e.g - * comes from an USB drive). This can allow a non-readable file - * or directory to become readable. - * - * Only following redirects when redirects are enabled disables - * this attack vector when not necessary. - */ - err = -EPERM; - if (d.redirect && !ovl_redirect_follow(ofs)) { - pr_warn_ratelimited("refusing to follow redirect for (%pd2)\n", - dentry); - goto out_put; - } + if (d.redirect) + d.nextredirect = true; if (d.stop) break; @@ -1218,6 +1239,11 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, ctr++; } + if (!ovl_check_nextredirect(&d)) { + err = -EPERM; + goto out_put; + } + /* * For regular non-metacopy upper dentries, there is no lower * path based lookup, hence ctr will be zero. If a dentry is found @@ -1307,11 +1333,18 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, upperredirect = NULL; goto out_free_oe; } + d.nextredirect = upperredirect; + err = ovl_check_metacopy_xattr(ofs, &upperpath, NULL); if (err < 0) goto out_free_oe; - uppermetacopy = err; + d.nextmetacopy = uppermetacopy = err; metacopy_size = err; + + if (!ovl_check_nextredirect(&d)) { + err = -EPERM; + goto out_free_oe; + } } if (upperdentry || ctr) { From patchwork Tue Apr 8 15:40:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 14043205 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 134181553AA for ; Tue, 8 Apr 2025 15:40:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126820; cv=none; b=QG501rRpg5I4wGazyXoom9QCCMtQo6BDLvTfk6Kmp6ZefsDU3chGISsEKp+XZbIYfPOYyy8slGRVCZsiHRUZjU7rGgxjkUX0MxfBJ/UGLJlG87DEuL7NyhyPAP+enXbPj0jq7uEDTmvwVRvsrYm44mw6aniiaYZBN4BUa20Pmdc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126820; c=relaxed/simple; bh=6VNMoxYzbFk+VlKL7h88wDZ9Ynzzobrg4jsDJKB20sw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lKMFkRhrb50JakR2Q3/cKDWwSEKmOrhualQ4HXVa4hUcqMtY6EFf5KQ7VlTP1KLzJ/v/lXK2hbnztAIxT/32yruV9MKtvP0isrboKzzsXyeCWZM3s5V+3RtQl4dp6QIwLRY53cZr6E4zuJRYxpKd0JbY2u9oXE87dOXy6ew+wtg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eJ/D825T; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eJ/D825T" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744126817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g4xX7nQQJU6qGcbsTCbaOngAfrHbt+AL1BwlUbjEmks=; b=eJ/D825TLriWRf7sNx+0nd+GRkDmWNA2fmDX7/7GKlcDsKOjxFAlaXiWPWh/1bywO9rWIj fHemjbTWsvdYo5IMI3VQANdsTvIElwoUmT5sH+01dSvp0Goc1fWCHLQm/xTgyGUCZ+55s2 SsDUs8qVAONl4PUlhAROGToeS0OBy8g= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-684-KC_2NOHWOX62v5FJu-5gBA-1; Tue, 08 Apr 2025 11:40:17 -0400 X-MC-Unique: KC_2NOHWOX62v5FJu-5gBA-1 X-Mimecast-MFC-AGG-ID: KC_2NOHWOX62v5FJu-5gBA_1744126816 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-ac28f255a36so476735766b.3 for ; Tue, 08 Apr 2025 08:40:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744126815; x=1744731615; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g4xX7nQQJU6qGcbsTCbaOngAfrHbt+AL1BwlUbjEmks=; b=V78ZNliEjTwUUd1b3L2cBNroEjADQXSwlfHJeEQd1TQ2L5WFA7G7vREiPyUyNA+fRY X8vFwlE5GzmreOzDe9GpSdjeDKSqa2aJ6zUxVejKdsO6P3N+cH/Bh36/JgOQdw/1joIG OF4E/oyc3X1vA7rbaarTOTWXhVjISIBmIFA+nrBnoQN0s5gD5ugNxucLbqR/GEv8YpLv 9q9WrD5zQPi80uXSfaRY7G+gW9QxE4GMGtR6TKtp5+MAnuKlA4qjKbo4JotpBzVTSgqM zHyOfrMSEfIsz1JFyU4lTUlWYqEAg3tEzfbe4DkrNnJsdXfGldQf+rXnN0Y7J58AlSAR fpLA== X-Forwarded-Encrypted: i=1; AJvYcCVidhyzwFgSAiSvMxIyQns0L0uAC5fSFRCXsfjZlQx5J4AT3HfVyr4TV10H/7jM+kRtKWfaP/TskMqUGKtX@vger.kernel.org X-Gm-Message-State: AOJu0Yw/ka/TIpNzDOFyNO3+wiVsjA04bPMyRqKBpIA+KzmNPtlXoMK9 9GgY9SdMm2Al8NaS7R4V2wvdbRt8NXKNl3pKRhh/xGiQpV81k6VvFOZlqnhPEBSXzqkH0l0JOcs o+RvqJwGEURPfwPrsIXTofiZmT4nHh8k7gxl1xSjaJHovO8fhIKCC6FRnVyaWJXPvUvL8PFo= X-Gm-Gg: ASbGnctipSo2cEqK60/w8bjA7Pc1s0/v90CGF7jUPnCF2CgzBGDZM3kkh7MF6F9zQYV XcIxafgYowNPXUNzA9R7ktJhr7EPy6wXihruZR0l9G8mBYgN0fux80MhLr7f6q0ofZSIFG2x3TO h08hmntXOiAw6RYoAcdPn/ZiGIYCcLAkVlRIJUcV+E7UX8vO9a7ARAXLJgzfIfsebOGDbI44cD6 NUKOoVrEqEMkAwgUrZrug+etVbsAcSNxxgykpFFU0QS13dPMqRfB75Fn/kKui+ga2DAK36LcVtH KTatrtogQCD+9annUGhNguLapZ+qxRa8O98agJAzSEcpEPNDnOYmimkldOUOthDDKEKa4RGd X-Received: by 2002:a17:907:1ca8:b0:ac1:fa91:2b98 with SMTP id a640c23a62f3a-ac7d6d00dafmr1619424466b.14.1744126815484; Tue, 08 Apr 2025 08:40:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG8aLezkLhIOxoF3ubbNutZOtgZSeu+nF9/yCx5dLPuyit/AbsIcKCEyAJEIEGs3zk4DrLqig== X-Received: by 2002:a17:907:1ca8:b0:ac1:fa91:2b98 with SMTP id a640c23a62f3a-ac7d6d00dafmr1619421266b.14.1744126815056; Tue, 08 Apr 2025 08:40:15 -0700 (PDT) Received: from maszat.piliscsaba.szeredi.hu (193-226-212-63.pool.digikabel.hu. [193.226.212.63]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c01bb793sm927553766b.161.2025.04.08.08.40.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 08:40:14 -0700 (PDT) From: Miklos Szeredi To: linux-unionfs@vger.kernel.org Cc: Amir Goldstein , linux-fsdevel@vger.kernel.org, Giuseppe Scrivano , Alexander Larsson Subject: [PATCH v3 2/3] ovl: relax redirect/metacopy requirements for lower -> data redirect Date: Tue, 8 Apr 2025 17:40:03 +0200 Message-ID: <20250408154011.673891-3-mszeredi@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408154011.673891-1-mszeredi@redhat.com> References: <20250408154011.673891-1-mszeredi@redhat.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Allow the special case of a redirect from a lower layer to a data layer without having to turn on metacopy. This makes the feature work with userxattr, which in turn allows data layers to be usable in user namespaces. Minimize the risk by only enabling redirect from a single lower layer to a data layer iff a data layer is specified. The only way to access a data layer is to enable this, so there's really no reason not to enable this. This can be used safely if the lower layer is read-only and the user.overlay.redirect xattr cannot be modified. Signed-off-by: Miklos Szeredi Reviewed-by: Amir Goldstein --- Documentation/filesystems/overlayfs.rst | 7 +++++++ fs/overlayfs/namei.c | 14 ++++++++------ fs/overlayfs/params.c | 5 ----- 3 files changed, 15 insertions(+), 11 deletions(-) diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 2db379b4b31e..4133a336486d 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -443,6 +443,13 @@ Only the data of the files in the "data-only" lower layers may be visible when a "metacopy" file in one of the lower layers above it, has a "redirect" to the absolute path of the "lower data" file in the "data-only" lower layer. +Instead of explicitly enabling "metacopy=on" it is sufficient to specify at +least one data-only layer to enable redirection of data to a data-only layer. +In this case other forms of metacopy are rejected. Note: this way data-only +layers may be used toghether with "userxattr", in which case careful attention +must be given to privileges needed to change the "user.overlay.redirect" xattr +to prevent misuse. + Since kernel version v6.8, "data-only" lower layers can also be added using the "datadir+" mount options and the fsconfig syscall from new mount api. For example:: diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index 5cebdd05ab3a..3d99e5fe5cfc 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -1068,6 +1068,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, struct inode *inode = NULL; bool upperopaque = false; char *upperredirect = NULL; + bool check_redirect = (ovl_redirect_follow(ofs) || ofs->numdatalayer); struct dentry *this; unsigned int i; int err; @@ -1080,7 +1081,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, .is_dir = false, .opaque = false, .stop = false, - .last = ovl_redirect_follow(ofs) ? false : !ovl_numlower(poe), + .last = check_redirect ? false : !ovl_numlower(poe), .redirect = NULL, .metacopy = 0, .nextredirect = false, @@ -1152,7 +1153,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, goto out_put; } - if (!ovl_redirect_follow(ofs)) + if (!check_redirect) d.last = i == ovl_numlower(poe) - 1; else if (d.is_dir || !ofs->numdatalayer) d.last = lower.layer->idx == ovl_numlower(roe); @@ -1233,13 +1234,14 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, } } - /* Defer lookup of lowerdata in data-only layers to first access */ + /* + * Defer lookup of lowerdata in data-only layers to first access. + * Don't require redirect=follow and metacopy=on in this case. + */ if (d.metacopy && ctr && ofs->numdatalayer && d.absolute_redirect) { d.metacopy = 0; ctr++; - } - - if (!ovl_check_nextredirect(&d)) { + } else if (!ovl_check_nextredirect(&d)) { err = -EPERM; goto out_put; } diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c index 6759f7d040c8..2468b436bb13 100644 --- a/fs/overlayfs/params.c +++ b/fs/overlayfs/params.c @@ -1025,11 +1025,6 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx, */ } - if (ctx->nr_data > 0 && !config->metacopy) { - pr_err("lower data-only dirs require metacopy support.\n"); - return -EINVAL; - } - return 0; } From patchwork Tue Apr 8 15:40:04 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 14043206 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 33CA522B8A1 for ; Tue, 8 Apr 2025 15:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126823; cv=none; b=HPcMp6y0RVXNhUERdRd4ImT6Z4Mbh6SIn4HpSRgF+DUoeLiwegNurvuwCxGhlCxK19waI+WpZSqWDOaFI2XQg+MoZJkYbacDbKP6X6OYes4RDGk3lnC9EY5cvV+HefyNFauLxPJ/uRi22f4K7jvzfwkYxpE7Fx2UFneinDJ5WMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744126823; c=relaxed/simple; bh=3OqX7/HXnAJ7kWQYc8jrodPhsTz38Nm57Ur1bhCHh+U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UmHoAxesZFFfrQZ7E/muLps8FNv0lW5AgvvWudFdN6FklfZesuElzROguoJ0kWg0IFUN578eIALDQyDROu/RK5I2CZ5JR+IcpZpx45LECfOPF1gpah+q70ZWvXPV/5pVxTxBYdiU6sUGgE8EgFpcPOYC70Ebzp3fRbv2X4h2H3w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=i75VhIwH; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="i75VhIwH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744126818; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PN6AWjrtRHghDIIvCf4IOAVUwqVcmDLtwrlJMGXZbVE=; b=i75VhIwHedMZsVWuNTAxp7KVzbFMwQjlNMkodPj/qTWYFouJAQsEXYRN31S2rKQn4E1lvF /ezvuWYJsg4EtZVJC+Nik3s5DF4bOu8Be0DJ6zUIs5bbzZL/5QF7q2gDpaXxyWJRXlBUH8 tBbJ96UZ9SEIfyjZVXLqBBylwVyvI6w= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-459-l0D0Q4r9Mmi-q2L8TbS-2g-1; Tue, 08 Apr 2025 11:40:17 -0400 X-MC-Unique: l0D0Q4r9Mmi-q2L8TbS-2g-1 X-Mimecast-MFC-AGG-ID: l0D0Q4r9Mmi-q2L8TbS-2g_1744126816 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-ac25852291cso578330566b.2 for ; Tue, 08 Apr 2025 08:40:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744126816; x=1744731616; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PN6AWjrtRHghDIIvCf4IOAVUwqVcmDLtwrlJMGXZbVE=; b=PSdS805s/MjMzHPDxaJArxDDdMKl1PiLx4hVXzNN9vLcucoBvzLLsK2+U1LpqcZbAg /T26yFSlX1tjWaXxcJuRcqVXw2GKtapP0IE4MIsuFr21U/HEL6Icr8QsJA+F/Dm0BbM4 CFeWblBXM/k3QDdqmMpii5DxmDpYV+dRbbxhiiFb1Cf7Bi4TljO3L+GRo5a6PsO/5q81 C7xT9ZfSDNNOU+E6onuoTVzDf+FI70+XhFhnq30S694QvqSTaoc6+zuSE3Bjq6WYxRfS iRI8coWmkk3beD1ngpT1GmAuzpz8c+wQHGTzCskPv7jc0IIoWSXlSBtTub0ZsIpHQITL tKzw== X-Forwarded-Encrypted: i=1; AJvYcCUA7toQOoNhIYcyZ68zBAAZgGJAczBY64bUNMUutpmIfY9h3n3xyv26Dhqyw9Rp2OeEodwgc8nIgR4Ii0Bf@vger.kernel.org X-Gm-Message-State: AOJu0YxJUj6Pzbrsov48bG8/cz35NJL+de4NrEP5fx7KPuQfme1ntUXF g+5cNXpmR50wxkUhCTaJFJfaHmrRQvhIxKyaPIqLXlUNYk+2ShU3a0XHU9KWmWk6KMwQdffgxTn QIhxY+BoF9cTLDwziTSxed57DBea4MSqgrAqpGtp7PGF5YF5S0F+K1tIgRhMJgTc= X-Gm-Gg: ASbGncucRY4i8TLYpwzaG1OD8FzSuTuMz2igyvLkJfTYLIBSo2yhCW779MvqrWPETCe rG1EMjbLqQJnF5iOlad3Mrj8hPImTU3Qk/WEJ7QaAMo3lMamZKSF7ffFTj2HOU6jWoWnR3uW71u NYCWmoOhtDAv3NEsDqaM5W6E8U+IiwNcq3gLRUNXI0MDon28XWn6z4aVwXAeyF2O2jwsY43NFYw HJxRqQrJfd9HxTkKFl3eOh4NykQAbG9Da9H3i9ISTQPvzTw+6pILQJmsK0Jj1nACcukaMn364Pu ANkW0IxoSPlXkkPrPXp9izUN9zgqSOisD1XvV2tYLcEzFZDwTdTFMMMDf8axLPeL93GyVf7L X-Received: by 2002:a17:906:5a4b:b0:ac7:e492:40d with SMTP id a640c23a62f3a-ac7e49209ddmr1102000666b.32.1744126816369; Tue, 08 Apr 2025 08:40:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHj8lXffDci56FA1P0NxUfnXmOBj0Hc3hmrjp4qZZ1KQy4AcmxFhC8j1v3veuCkfZ6qbLKmOw== X-Received: by 2002:a17:906:5a4b:b0:ac7:e492:40d with SMTP id a640c23a62f3a-ac7e49209ddmr1101999166b.32.1744126815959; Tue, 08 Apr 2025 08:40:15 -0700 (PDT) Received: from maszat.piliscsaba.szeredi.hu (193-226-212-63.pool.digikabel.hu. [193.226.212.63]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c01bb793sm927553766b.161.2025.04.08.08.40.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 08:40:15 -0700 (PDT) From: Miklos Szeredi To: linux-unionfs@vger.kernel.org Cc: Amir Goldstein , linux-fsdevel@vger.kernel.org, Giuseppe Scrivano , Alexander Larsson Subject: [PATCH v3 3/3] ovl: don't require "metacopy=on" for "verity" Date: Tue, 8 Apr 2025 17:40:04 +0200 Message-ID: <20250408154011.673891-4-mszeredi@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408154011.673891-1-mszeredi@redhat.com> References: <20250408154011.673891-1-mszeredi@redhat.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 This allows the "verity" mount option to be used with "userxattr" data-only layer(s). Also it allows dropping the "metacopy=on" option when the "datadir+" option is to be used. This cleanly separates the two features that have been lumped together under "metacopy=on": - data-redirect: data access is redirected to the data-only layer - meta-copy: copy up metadata only if possible Previous patches made sure that with "userxattr" metacopy only works in the lower -> data scenario. In this scenario the lower (metadata) layer must be secured against tampering, in which case the verity checksums contained in this layer can ensure integrity of data even in the case of an untrusted data layer. Signed-off-by: Miklos Szeredi Reviewed-by: Amir Goldstein --- fs/overlayfs/params.c | 26 ++------------------------ 1 file changed, 2 insertions(+), 24 deletions(-) diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c index 2468b436bb13..e297681ecac7 100644 --- a/fs/overlayfs/params.c +++ b/fs/overlayfs/params.c @@ -871,18 +871,6 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx, config->uuid = OVL_UUID_NULL; } - /* Resolve verity -> metacopy dependency */ - if (config->verity_mode && !config->metacopy) { - /* Don't allow explicit specified conflicting combinations */ - if (set.metacopy) { - pr_err("conflicting options: metacopy=off,verity=%s\n", - ovl_verity_mode(config)); - return -EINVAL; - } - /* Otherwise automatically enable metacopy. */ - config->metacopy = true; - } - /* * This is to make the logic below simpler. It doesn't make any other * difference, since redirect_dir=on is only used for upper. @@ -890,18 +878,13 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx, if (!config->upperdir && config->redirect_mode == OVL_REDIRECT_FOLLOW) config->redirect_mode = OVL_REDIRECT_ON; - /* Resolve verity -> metacopy -> redirect_dir dependency */ + /* metacopy -> redirect_dir dependency */ if (config->metacopy && config->redirect_mode != OVL_REDIRECT_ON) { if (set.metacopy && set.redirect) { pr_err("conflicting options: metacopy=on,redirect_dir=%s\n", ovl_redirect_mode(config)); return -EINVAL; } - if (config->verity_mode && set.redirect) { - pr_err("conflicting options: verity=%s,redirect_dir=%s\n", - ovl_verity_mode(config), ovl_redirect_mode(config)); - return -EINVAL; - } if (set.redirect) { /* * There was an explicit redirect_dir=... that resulted @@ -970,7 +953,7 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx, } - /* Resolve userxattr -> !redirect && !metacopy && !verity dependency */ + /* Resolve userxattr -> !redirect && !metacopy dependency */ if (config->userxattr) { if (set.redirect && config->redirect_mode != OVL_REDIRECT_NOFOLLOW) { @@ -982,11 +965,6 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx, pr_err("conflicting options: userxattr,metacopy=on\n"); return -EINVAL; } - if (config->verity_mode) { - pr_err("conflicting options: userxattr,verity=%s\n", - ovl_verity_mode(config)); - return -EINVAL; - } /* * Silently disable default setting of redirect and metacopy. * This shall be the default in the future as well: these