linux-kernel - Re: [V9fs-developer] [PATCH RFC 0/4] 9p: fix open-unlink-f*syscall bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200914174630.195e816f@bahia.lan>
Date:   Mon, 14 Sep 2020 17:46:30 +0200
From:   Greg Kurz <groug@...d.org>
To:     Christian Schoenebeck <qemu_oss@...debyte.com>
CC:     Jianyong Wu <jianyong.wu@....com>, <ericvh@...il.com>,
        <lucho@...kov.net>, <asmadeus@...ewreck.org>,
        <v9fs-developer@...ts.sourceforge.net>, <justin.he@....com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [V9fs-developer] [PATCH RFC 0/4] 9p: fix open-unlink-f*syscall
 bug

On Mon, 14 Sep 2020 17:19:20 +0200
Christian Schoenebeck <qemu_oss@...debyte.com> wrote:

> On Montag, 14. September 2020 14:43:25 CEST Greg Kurz wrote:
> > > So yes, looks like this also requires changes to the 9pfs 'local' fs
> > > driver on QEMU side:
> > > https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg07586.html
> > > 
> > > Eric, Greg, would there be an easy way to establish QEMU test cases
> > > running
> > > the 9pfs 'local' fs driver? Right now we only have 9pfs qtest cases for
> > > QEMU which can only use the 'synth' driver, which is not helpful for such
> > > kind of issues.
> > 
> > I guess it's possible to introduce new qtests that start QEMU with
> > -fsdev local instead of -fsdev synth... I haven't looked in a while
> > though, so I won't comment on "easy way" ;-)
> 
> Makes sense, and I considered that approach as well.
> 
> The question is the following: is there a QEMU policy about test cases that 
> create/write/read/delete *real* files? I.e. should those test files be written 
> to a certain location, and are there measures of sandboxing required?
> 

I don't know. You'll need to figure out by yourself, reading code from
other tests or asking on IRC.

> Best regards,
> Christian Schoenebeck
> 
>