qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: "Christian Schoenebeck" <qemu_oss@crudebyte.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Greg Kurz" <groug@kaod.org>,
	"Antonios Motakis" <antonios.motakis@huawei.com>
Subject: Re: [Qemu-devel] [PATCH v5 3/5] 9p: Added virtfs option 'remap_inodes'
Date: Sun, 01 Sep 2019 21:35:56 +0200	[thread overview]
Message-ID: <1656463.NAo3fzYekE@silver> (raw)
In-Reply-To: <20190830134827.326dc87a@bahia.lan>

On Freitag, 30. August 2019 13:48:27 CEST Greg Kurz wrote:
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index 8cc65c2c67..39c6c2a894 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> > 
> > [snip]
> > 
> > > @@ -1940,6 +2041,19 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU
> > > *pdu, V9fsFidState *fidp, int32_t count = 0;
> > > 
> > >      off_t saved_dir_pos;
> > >      struct dirent *dent;
> > > 
> > > +    struct stat stbuf;
> > > +    bool fidIsExportRoot;
> > > +
> > > +    /*
> > > +     * determine if fidp is the export root, which is required for safe
> > > +     * handling of ".." below
> > > +     */
> > > +    err = v9fs_co_lstat(pdu, &fidp->path, &stbuf);
> > > +    if (err < 0) {
> > > +        return err;
> > > +    }
> > > +    fidIsExportRoot = pdu->s->dev_id == stbuf.st_dev &&
> > > +                      pdu->s->root_ino == stbuf.st_ino;
> > > 
> > >      /* save the directory position */
> > >      saved_dir_pos = v9fs_co_telldir(pdu, fidp);
> > > 
> > > @@ -1964,16 +2078,51 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU
> > > *pdu, V9fsFidState *fidp, v9fs_string_free(&name);
> > > 
> > >              return count;
> > >          
> > >          }
> > > 
> > > -        /*
> > > -         * Fill up just the path field of qid because the client uses
> > > -         * only that. To fill the entire qid structure we will have
> > > -         * to stat each dirent found, which is expensive
> > > -         */
> > > -        size = MIN(sizeof(dent->d_ino), sizeof(qid.path));
> > > -        memcpy(&qid.path, &dent->d_ino, size);
> > > -        /* Fill the other fields with dummy values */
> > > -        qid.type = 0;
> > > -        qid.version = 0;
> > > +
> > > +        if (fidIsExportRoot && !strcmp("..", dent->d_name)) {
> > > +            /*
> > > +             * if "." is export root, then return qid of export root
> > > for
> > > +             * ".." to avoid exposing anything outside the export
> > > +             */
> > > +            err = fid_to_qid(pdu, fidp, &qid);
> > > +            if (err < 0) {
> > > +                v9fs_readdir_unlock(&fidp->fs.dir);
> > > +                v9fs_co_seekdir(pdu, fidp, saved_dir_pos);
> > > +                v9fs_string_free(&name);
> > > +                return err;
> > > +            }
> > 
> > Hmm, I start to wonder whether I should postpone that particular bug fix
> > and not make it part of that QID fix patch series (not even as separate
> > patch there). Because that fix needs some more adjustments. E.g. I should
> > adjust dent->d_type here as well; but more notably it should also
> > distinguish between the case where the export root is mounted as / on
> > guest or not and that's where this fix could become ugly and grow in
> > size.
> > 
> > To make the case clear:  calling on guest
> > 
> > 	readdir(pathOfSome9pExportRootOnGuest);
> > 
> > currently always returns for its ".." result entry the inode number and
> > d_type of the export root's parent directory on host, so it exposes
> > information of host outside the 9p export.
> > 
> > I don't see that as security issue, since the information revealed is
> > limited to the inode number and d_type, but it is definitely incorrect
> > behaviour.
> Definitely. This should be fixed independently of this series. Maybe follow
> the same approach as commit 56f101ecce0e "9pfs: handle walk of ".." in the
> root directory", ie. basically make /.. an alias of /.

That's actually what the suggested fix already did in v5 here (see diff above). 
However I was worried whether I thought about all edge cases. So I also need 
some more testing and hence clearly decided to postpone this fix for now.

Best regards,
Christian Schoenebeck



  reply	other threads:[~2019-09-01 19:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03 11:44 [Qemu-devel] [PATCH v5 0/5] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-07-03 10:55 ` [Qemu-devel] [PATCH v5 1/5] 9p: unsigned type for type, version, path Christian Schoenebeck via Qemu-devel
2019-07-31 19:14   ` Greg Kurz
2019-07-03 11:01 ` [Qemu-devel] [PATCH v5 2/5] 9p: Treat multiple devices on one export as an error Christian Schoenebeck via Qemu-devel
2019-07-31 20:30   ` Greg Kurz
2019-07-03 11:13 ` [Qemu-devel] [PATCH v5 3/5] 9p: Added virtfs option 'remap_inodes' Christian Schoenebeck via Qemu-devel
2019-07-06 10:22   ` Christian Schoenebeck via Qemu-devel
2019-08-30 11:48     ` Greg Kurz
2019-09-01 19:35       ` Christian Schoenebeck via Qemu-devel [this message]
2019-07-03 11:17 ` [Qemu-devel] [PATCH v5 4/5] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-07-03 11:27 ` [Qemu-devel] [PATCH v5 5/5] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-07-03 15:46 ` [Qemu-devel] [PATCH v5 0/5] 9p: Fix file ID collisions no-reply
2019-07-03 16:04 ` no-reply

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=1656463.NAo3fzYekE@silver \
    --to=qemu-devel@nongnu.org \
    --cc=antonios.motakis@huawei.com \
    --cc=berrange@redhat.com \
    --cc=groug@kaod.org \
    --cc=qemu_oss@crudebyte.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).