All of lore.kernel.org
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Cc: ddis@suse.com, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH 1/3] Btrfs-progs: fix mount point detection due to partial prefix match
Date: Mon, 14 Jan 2019 13:30:24 +0000	[thread overview]
Message-ID: <20190114133024.18320-1-fdmanana@kernel.org> (raw)

From: Filipe Manana <fdmanana@suse.com>

When attempting to find the mount point of a path we can end up returning
an incorrect mount point. This happens because we consider a mount point
valid for the given path even if it matches only partially the patch.
Consider the following example, which makes btrfs receive fail:

  $ truncate -s 1G disk1
  $ truncate -s 1G disk2

  $ losetup /dev/loop1 disk1
  $ losetup /dev/loop2 disk2

  $ mkfs.btrfs -f /dev/loop1
  $ mkfs.btrfs -f /dev/loop2

  $ mount /dev/loop1 /mnt
  $ mkdir /mnt/ddis
  $ mkdir /mnt/ddis-not-a-mount
  $ mount /dev/loop2 /mnt/ddis

  $ echo "some data" > /mnt/ddis/file
  $ btrfs subvolume snapshot -r /mnt/ddis /mnt/ddis/snap

  $ btrfs send -f /tmp/send.data /mnt/ddis/snap
  $ btrfs receive -f /tmp/send.data /mnt/ddis-not-a-mount
  At subvol snap
  ERROR: chown  failed: No such file or directory

In that example btrfs receive passes the path "/mnt/ddis-not-a-mount" to
find_mount_root() which picks "/mnt/ddis" as the mount point instead of
"/mnt". The wrong decision happens because "/mnt/ddis" is the longest
string found that is a prefix of "/mnt/ddis-not-a-mount", however it
shouldn't be considered valid because what follows the substring "ddis"
in the given path is not a path separator ("/") nor the null character
('\0'). So fix find_mount_root() to check for the presence of a path
separator or a null byte character after if finds a mount point string
that matches the given path.

A test case will follow soon in a separate patch.

Reported-by: David Disseldorp <ddis@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
 utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index 3a4bc92a..6616630b 100644
--- a/utils.c
+++ b/utils.c
@@ -2064,7 +2064,8 @@ int find_mount_root(const char *path, char **mount_root)
 
 	while ((ent = getmntent(mnttab))) {
 		len = strlen(ent->mnt_dir);
-		if (strncmp(ent->mnt_dir, path, len) == 0) {
+		if (strncmp(ent->mnt_dir, path, len) == 0 &&
+		    (path[len] == '/' || path[len] == '\0')) {
 			/* match found and use the latest match */
 			if (longest_matchlen <= len) {
 				free(longest_match);
-- 
2.11.0


             reply	other threads:[~2019-01-14 13:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 13:30 fdmanana [this message]
2019-01-14 13:59 ` [PATCH 1/3] Btrfs-progs: fix mount point detection due to partial prefix match David Disseldorp
2019-01-14 14:12   ` Filipe Manana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190114133024.18320-1-fdmanana@kernel.org \
    --to=fdmanana@kernel.org \
    --cc=ddis@suse.com \
    --cc=fdmanana@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.