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
