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
next prev parent 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).