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

[Christian Schoenebeck]

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