qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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




  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).