[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
- RE: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, (continued)
- RE: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Shi, Guohuai, 2022/05/09
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Christian Schoenebeck, 2022/05/10
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Christian Schoenebeck, 2022/05/10
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Greg Kurz, 2022/05/10
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Christian Schoenebeck, 2022/05/10
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Greg Kurz, 2022/05/10
- RE: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Shi, Guohuai, 2022/05/10
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Christian Schoenebeck, 2022/05/11
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Greg Kurz, 2022/05/11
- RE: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows, Shi, Guohuai, 2022/05/11
- Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows,
Christian Schoenebeck <=