Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities functions for 9pfs

[Christian Schoenebeck]

On Tuesday, November 1, 2022 4:20:53 PM CET Shi, Guohuai wrote:
> 
[...]
> > > > Windows POSIX API and MinGW library do not provide the NO_FOLLOW
> > > > flag, and do not allow opening a directory by POSIX open(). This
> > > > causes all
> > > > xxx_at() functions cannot work directly. However, we can provide
> > > > Windows handle based functions to emulate xxx_at() functions (e.g.:
> > > > openat_win32, utimensat_win32, etc.).
> > > >
> > > > Windows does not support extended attributes. 9pfs for Windows uses
> > > > NTFS ADS (Alternate Data Streams) to emulate extended attributes.
> > > >
> > > > Windows does not provide POSIX compatible readlink(), and symbolic
> > > > link feature in 9pfs will be disabled on Windows.
> > >
> > > Wouldn't it be more user friendly if the relevant error locations
> > > would use something like error_report_once() and suggesting to enable
> > > mapped(-xattr) to make 9p symlinks on guest working if desired by the 
> > > user?
> > >
> > > Probably this error case would need to wrapped into a dedicated
> > > function, otherwise I guess error_report_once() would fire several
> > > times by different callers.
> > >
> > 
> > Windows (MinGW) does not only support symlink, but also does not have 
> > symlink
> > definitions.
> > Windows does not support symlink flags S_IFLNK.
> > 
> > So even I add symlink support by mapped-xattr, the MinGW library does not
> > have symlink flags and get a build error.
> > And this flags is defined by Windows header files.
> > The impact of adding a new flags to an pre-defined structure (struct stat) 
> > is
> > unknown.
> > 
> > So I think it is not a good idea to do that.
> 
> Because Windows does not support symlink, so error_report_once() and report 
> it to user will be OK.
> But mapped-xattr could not work.

Showing an error makes sense for "passthrough" security model, but not for the
"mapped" one.

Just to avoid misapprehensions: are you aware that there is already a system-
agnostic implementation for symlinks if "mapped" is used?

When mapped security model is enabled, then creating symlinks on guest will
simply create a corresponding *regular* file on host and the content of that
regular file on host is the pointing path as raw string. Additionally the
symlink flag is added to "virtfs.mode" xattr to mark that regular file as a
symlink, a virtual one that is. So this does not require any support for
symlinks by either the underlying host file system, nor by host OS.

Likewise interpreting and walking those virtual symlinks in "mapped" mode is
also implemented in the local fs driver already.

Best regards,
Christian Schoenebeck