From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org, "Meng, Bin" <Bin.Meng@windriver.com>
Cc: Greg Kurz <groug@kaod.org>, Bin Meng <bmeng.cn@gmail.com>,
"Shi, Guohuai" <Guohuai.Shi@windriver.com>
Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows
Date: Wed, 11 May 2022 13:18:45 +0200 [thread overview]
Message-ID: <18993050.BCn1JD0qEJ@silver> (raw)
In-Reply-To: <MN2PR11MB4173011DDC017F9A414382BEEFC99@MN2PR11MB4173.namprd11.prod.outlook.com>
On Dienstag, 10. Mai 2022 17:35:10 CEST Shi, Guohuai wrote:
> Let's force on the security issue:
>
> Firstly, this answer (
> https://stackoverflow.com/questions/32138524/is-there-a-windows-equivalent-> of-openat ) is useless for QEMU. It uses Windows native API NtCreateFile()
> and accesses files by Windows handle. But 9PFS is using Windows POSIX
> interface, handle can not be used in POSIX interface. Actually, Windows
> provide similar APIs like
> GetFinalPathNameByHandle()/GetFileInformationByHandle(). It can also get
> file information by Windows handle.
I find "useless" quite exaggerated. You probably can't mix NT API calls with
Mingw library calls, not sure, haven't checked the Mingw sources.
If there is no way with Mingw to resolve NT handles, then it is still possible
however to implement all the POSIX functions we need (using NT API
exclusively) in 9p-util-win.c.
Another option would be contributing the missing features to Mingw and in turn
let QEMU's 9p feature depend on the appropriate minimum Mingw version.
> Windows POSIX interface do not support NO_FOLLOW flags, that means, Windows
> POSIX open() always translate symbolic link.
>
> So everything are finally point to one limitation: Windows POSIX interfaces
> do not support symbolic link and always translate link.
>
> For the security reason, I think it is reasonable to disable symbolic link
> support on Windows host for 9PFS. I can re-work this patch to adding a
> symbolic link check during path-walk operation and stop it when get a
> symbolic link.
It is OK to drop support for native symlinks on Windows. Most people use
security_model=mapped anyway where symlinks are emulated, so symlinks would
still work for guests, even if Windows host would not support native symlinks.
However insecure code is still a no go. So the issues identified so far still
need to be resolved.
And patches must be presented in a way that would allow them being reviewed.
In their current form they are not.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-05-11 11:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 14:26 [PATCH 0/9] 9pfs: Add 9pfs support for Windows host Bin Meng
2022-04-25 14:26 ` [PATCH 1/9] hw/9pfs: Compile 9p-local.c and 9p-proxy.c for Linux and macOS Bin Meng
2022-04-25 14:26 ` [PATCH 2/9] qemu/xatth.h: Update for Windows build Bin Meng
2022-04-25 14:26 ` [PATCH 3/9] hw/9pfs: Extract common stuff to 9p-local.h Bin Meng
2022-04-25 14:27 ` [PATCH 4/9] fsdev: Add missing definitions for Windows in file-op-9p.h Bin Meng
2022-05-04 17:35 ` Christian Schoenebeck
2022-04-25 14:27 ` [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for Windows Bin Meng
2022-05-04 18:01 ` Christian Schoenebeck
2022-05-04 19:34 ` Shi, Guohuai
2022-05-05 11:43 ` Christian Schoenebeck
2022-05-06 6:46 ` Shi, Guohuai
2022-05-09 14:29 ` Greg Kurz
2022-05-09 15:09 ` Shi, Guohuai
2022-05-09 16:20 ` Greg Kurz
2022-05-10 2:13 ` Shi, Guohuai
2022-05-10 2:17 ` Shi, Guohuai
2022-05-10 10:18 ` Christian Schoenebeck
2022-05-10 11:54 ` Christian Schoenebeck
2022-05-10 13:40 ` Greg Kurz
2022-05-10 14:04 ` Christian Schoenebeck
2022-05-10 14:34 ` Greg Kurz
2022-05-10 15:35 ` Shi, Guohuai
2022-05-11 11:18 ` Christian Schoenebeck [this message]
2022-05-11 12:18 ` Greg Kurz
2022-05-11 15:57 ` Shi, Guohuai
2022-05-24 12:23 ` Christian Schoenebeck
2022-04-25 14:27 ` [PATCH 6/9] hw/9pfs: Update 9p-synth.c for Windows build Bin Meng
2022-04-25 14:27 ` [PATCH 7/9] fsdev: Enable 'local' file system driver backend for Windows Bin Meng
2022-04-25 14:27 ` [PATCH 8/9] meson.build: Turn on virtfs for Windows host Bin Meng
2022-04-25 14:27 ` [PATCH 9/9] hw/9p: win32: Translate Windows error number to Linux value Bin Meng
2022-05-04 18:15 ` Christian Schoenebeck
2022-04-26 1:41 ` [PATCH 0/9] 9pfs: Add 9pfs support for Windows host Bin Meng
2022-05-03 3:42 ` Bin Meng
2022-05-04 17:16 ` Christian Schoenebeck
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=18993050.BCn1JD0qEJ@silver \
--to=qemu_oss@crudebyte.com \
--cc=Bin.Meng@windriver.com \
--cc=Guohuai.Shi@windriver.com \
--cc=bmeng.cn@gmail.com \
--cc=groug@kaod.org \
--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).