qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Wi


From: Christian Schoenebeck
Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows
Date: Tue, 24 May 2022 14:23:27 +0200

On Mittwoch, 11. Mai 2022 17:57:08 CEST Shi, Guohuai wrote:
> > -----Original Message-----
> > From: Greg Kurz <groug@kaod.org>
> > Sent: 2022年5月11日 20:19
> > To: Shi, Guohuai <Guohuai.Shi@windriver.com>
> > Cc: Christian Schoenebeck <qemu_oss@crudebyte.com>; qemu-devel@nongnu.org;
> > Meng, Bin <Bin.Meng@windriver.com>; Bin Meng <bmeng.cn@gmail.com>
> > Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver
> > for Windows
[...]
> > This would be useless because of TOCTOU : a directory could be replaced by
> > a symlink between the check and the actual use of the file. O_NOFOLLOW
> > provides the atomicity needed to safely error out on symlinks. Since
> > O_NOFOLLOW only makes sense for the rightmost path element, paths from
> > the client have to be broken down into a succession of *at() syscalls,
> > one for each element.
> 
> 
> For Windows file system, it would be OK.
> Windows can not delete a opening file (this is different behavior between
> Windows file system driver and UNIX-like-inode-based file system). So when
> 9PFS try to open the final file, the following steps will keep it safe: 
> 1. open the final file by Windows NT APIs and keep the open handle.
> 2. open the final file by MinGW open().
> 3. close NT handle.
> 
> Windows file system does not allow delete/rename/move a opening file.
> Even Windows provide "FILE_SHARE_DELETE" flag in its NT API CreateFile().
> Windows allow to delete the opening file, but can not re-create same name.
> The following steps will be failure on Windows:
> 
> 1. Open a directory by CreateFile() with "FILE_SHARE_DELETE" flag and keep
> the handle open.
> 2. Remove the directory.
> 3. Re-create same name directory/file/links.
> 
> Windows will get failure on step #3.
> 
> So I think checking if there is a link in filename would be safety on Window
> host.

Neither Greg nor me are working much with Windows. As this was a fundamental 
security issue though, one way to bring this issue forward would be to backup 
your claims with test case(s). Then we would also have a safety net e.g. via 
CI cloud alerts in case behaviour on Windows changes one day.

Best regards,
Christian Schoenebeck





reply via email to

[Prev in Thread] Current Thread [Next in Thread]