From: Greg Kurz <groug@kaod.org>
To: qemu-devel@nongnu.org
Cc: virtio-fs@redhat.com, Miklos Szeredi <mszeredi@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>, Greg Kurz <groug@kaod.org>
Subject: [PATCH 0/3] virtiofsd: Deal with empty filenames
Date: Fri, 12 Mar 2021 15:10:00 +0100 [thread overview]
Message-ID: <20210312141003.819108-1-groug@kaod.org> (raw)
There's no such thing as an empty file name in POSIX-compliant file systems.
The current code base doesn't ensure the client doesn't send requests with
such empty names. I've audited the code and only found one place where
the behavior is somewhat altered in lookup_name() :
res = do_statx(lo, dir->fd, name, &attr,
AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW, &mnt_id);
lookup_name() is used by lo_rmdir(), lo_rename() and lo_unlink() which
all share the same behavior of doing some action on a file or directory
under a given parent directory. But if an empty name reaches the code
above, do_statx() returns the attributes of the parent directory itself
and lookup_name() might return the inode of the parent directory. This
could potentially cause security concerns in the callers.
Fortunately, it doesn't as of today. If the parent directory is the root
inode, lookup_name() returns NULL because lo_find() fails to find an
inode with a matching .st_dev. Otherwise, lookup_name() does return the
parent inode but the empty name then gets passed to either unlinkat(),
renameat() or renameat2(), all of which fail with ENOENT in this case.
Drop AT_EMPTY_PATH from the above code anyway to make it clear empty
names aren't expected by the existing callers. If the need for it
arises in the future, it can be added back but stay safe for now.
The FUSE protocol doesn't have a notion of AT_EMPTY_PATH actually. The
server should hence never see empty names in client requests. Detect
this early and systematically fail the request with ENOENT in this
case.
No regression is observed with the POSIX-oriented pjdfstest file system
test suite (https://github.com/pjd/pjdfstest).
Greg Kurz (3):
virtiofsd: Don't allow empty paths in lookup_name()
virtiofsd: Convert some functions to return bool
virtiofsd: Don't allow empty filenames
tools/virtiofsd/passthrough_ll.c | 44 ++++++++++++++++++++++++++++----
1 file changed, 39 insertions(+), 5 deletions(-)
--
2.26.2
next reply other threads:[~2021-03-12 14:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 14:10 Greg Kurz [this message]
2021-03-12 14:10 ` [PATCH 1/3] virtiofsd: Don't allow empty paths in lookup_name() Greg Kurz
2021-03-12 15:13 ` [Virtio-fs] " Connor Kuehl
2021-03-12 15:49 ` Greg Kurz
2021-03-14 23:38 ` Vivek Goyal
2021-03-12 14:10 ` [PATCH 2/3] virtiofsd: Convert some functions to return bool Greg Kurz
2021-03-12 15:13 ` [Virtio-fs] " Connor Kuehl
2021-03-14 23:36 ` Vivek Goyal
2021-03-12 14:10 ` [PATCH 3/3] virtiofsd: Don't allow empty filenames Greg Kurz
2021-03-12 15:13 ` [Virtio-fs] " Connor Kuehl
2021-03-14 23:36 ` Vivek Goyal
2021-03-15 10:06 ` Greg Kurz
2021-03-15 15:18 ` Dr. David Alan Gilbert
2021-03-15 17:37 ` Greg Kurz
2021-03-15 17:55 ` Vivek Goyal
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=20210312141003.819108-1-groug@kaod.org \
--to=groug@kaod.org \
--cc=dgilbert@redhat.com \
--cc=mszeredi@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).