qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	qemu-devel@nongnu.org, aliguori@amazon.com
Subject: Re: [Qemu-devel] [RESEND] [PATCH] hw/9pfs: fix P9_STATS_GEN handling
Date: Wed, 6 Nov 2013 19:33:57 +0200	[thread overview]
Message-ID: <20131106173357.GA22790@shutemov.name> (raw)
In-Reply-To: <8761s5tsqk.fsf@linux.vnet.ibm.com>

On Wed, Nov 06, 2013 at 09:41:47PM +0530, Aneesh Kumar K.V wrote:
> "Kirill A. Shutemov" <kirill@shutemov.name> writes:
> 
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> >
> > Currently we have few issues with P9_STATS_GEN:
> >
> >  - We don't try to read st_gen anything except files or directories, but
> >    still set P9_STATS_GEN bit in st_result_mask. It may mislead client:
> >    we present garbage as valid st_gen.
> 
> We should return 0 right ? We do 
> 
>     memset(v9lstat, 0, sizeof(*v9lstat));
> 
> in stat_to_v9stat_dotl

The right way is not set P9_STATS_GEN in st_result_mask if we don't know
it.

> >  - If we failed to get valid st_gen with ENOTTY, we ignore error, but
> >    still set P9_STATS_GEN bit in st_result_mask.
> 
> and have v9lstat.st_gen set to zero 

The same as above.

And if ioctl(fd, FS_IOC_GETVERSION, st_gen) fails, nobody specifies what
will be stored into st_gen, if any. We should not relay that fs will not
touch st_gen even if it sounds reasonable.

> 
> >
> >  - If we failed to get valid st_gen with any other errno, we fail
> >    getattr altogether. It's excessive: we block valid client use-cases,
> >    like chdir(2) to non-readable directory with execution bit set.
> >
> 
> Can you explain this in detail ? 

If you have following tree:
 
% mkdir testdir
% echo test > testdir/testfile
% chmod -r testdir
 
In normal environment it's usable: you can chdir(2) into it and read files
inside if you know its name:
 
% cd testdir
% cat testfile
test
 
You only can't list directory content:
 
% ls
ls: cannot open directory .: Permission denied
 
With current qemu 9p implementation you'll get on guest -EACCES on chdir(2)
or read, since qemu fill fail to provide basic stats to guess. It happens
because qemu try open(2) non-readable file to run FS_IOC_GETVERSION and
fails getattr altogether.
 
I believe it also breaks more trivial use-cases: ls -l on non-readable
file or directory for the same reason. But I haven't checked that.

-- 
 Kirill A. Shutemov

  reply	other threads:[~2013-11-06 18:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04  9:55 [Qemu-devel] [RESEND] [PATCH] hw/9pfs: fix P9_STATS_GEN handling Kirill A. Shutemov
2013-11-06 16:11 ` Aneesh Kumar K.V
2013-11-06 17:33   ` Kirill A. Shutemov [this message]
2013-11-07  6:45 ` Aneesh Kumar K.V

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=20131106173357.GA22790@shutemov.name \
    --to=kirill@shutemov.name \
    --cc=aliguori@amazon.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=qemu-devel@nongnu.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 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).