Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 17/04/2022 13:55, Christian Schoenebeck wrote:

> On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
>>> -----Original Message-----
>>> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
>>> Sent: 2022年4月14日 19:24
>>> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
>>> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
>>> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
>>>
>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>
>>> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
>>>
>>>>> We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
>>>>> it is in  bad shape and we will probably deprecate it in near future
>>>>> anyway. But it would be good to have support for the synth driver,
>>>>> because we are using it for running test cases and fuzzing tests
>>>>> (QA).
> [...]
>> For 9p-synth:
>>
>> I had enabled 9p-synth.c and built it successfully on Windows platform.
>> However, test cases code are not built on Windows host.
>> So I think it is useless that enable synth on Windows host (no way to run
>> it).
> 
> Please, don't give up too soon. Looking at tests/qtest/meson.build it starts
> with:
> 
> # All QTests for now are POSIX-only, but the dependencies are
> # really in libqtest, not in the testcases themselves.
> if not config_host.has_key('CONFIG_POSIX')
>    subdir_done()
> endif
> 
> And looking at tests/qtest/libqtest.c I "think" this should be working on
> Windows as well. It uses socket APIs which are available on Windows. I don't
> see a real show stopper here for Windows.
> 
> Could you please try if you can compile the tests on Windows? What we would
> need is test/qtest/qos-test, we don't need all the other tests:
> 
> https://wiki.qemu.org/Documentation/9p#Test_Cases
> 
>>>> It is possible that to "map" extend attribute to NTFS stream data.
>>>> However, if Windows host media is not NTFS (e.g. FAT) which does not
>>>> support stream data, then the "map" can not work.
>>>
>>> ... yes exactly, it would make sense to use ADS [4] instead of xattr on
>>> Windows. ADS are available with NTFS and ReFS and maybe also with exFAT
>>> nowadays (?), not sure about the latter though. But I think it is fair
>>> enough to assume Windows users to either use NTFS or ReFS. And if they
>>> don't, you can still call error_report_once() to make user aware that
>>> seucrity_model=mapped(-xattr) requires a fileystem on Windows that
>>> supports ADS.
>>> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
>>>
>>
>> Windows does not support POSIX permission.
>> So I think that only allow user to use security_model=none is reasonable on
>> Windows host.
> 
> It depends on the use case. I assume your use case are Windows guests, in that
> case you don't have the concept of POSIX permissions neither on guest side,
> nor on host side (on the long-term I am pretty sure though that Windows guest
> users would want to have some kind of Windows ACL mapping implementation as
> well).
> 
>> There is a difficulty to support "mapped" or "mapped-file" on Windows host:
>> There are many functions in 9p-code using APIs like "openat", "mkdirat",
>> etc. MSYS does not support that (openat is not valid on Windows host). I
>> remember that 9p replaced "open" by "openat" for a long time.
>> To fully support "security_model=mapped", 9p for Windows need to replace
>> "openat" by "open". This may impact too many functions.
>>
>> I would have a try to enable "mapped" by using ADS, but it looks like a big
>> refactor for 9p-local.c
> 
> Regarding openat(): We had a similar challenge for macOS host implementation;
> macOS does not have mknodat(), so what we're currently doing is
> 
>    pthread_fchdir_np(...)
>    mknod(...)
> 
>    https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84
> 
> So on Windows you could do:
> 
>    chdir(...)
>    open(...)
> 
> as workaround for providing openat() for msys.
> 
> For security_model=mapped(-xattr) to work on Windows you basically would need
> to provide a replacement implementation (based on Windows ADS) in
> 9p-util-windows.c for:
> 
>    ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char
>                                 *name, void *value, size_t size);
> 
>    ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
>                                  char *list, size_t size);
> 
>    ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
>                                    const char *name);
> 
>    int fsetxattrat_nofollow(int dirfd, const char *filename, const char *name,
>                             void *value, size_t size, int flags);
> 
> So it does not look too bad I think to get security_model=mapped working, and
> it would make Windows 9p host support much more usable (for Linux guests,
> macOS guests, but also for Windows guests with mapped Windows ACL in future).

FWIW even just having security_model=none would be very useful here, since then 9pfs 
could be used to share host files across all of Windows, MacOS and POSIX OSs which is 
something that can't yet be done with virtiofsd.

Whilst using ADS would allow the xattrs to be attached to files, how would this work 
in the case of ACLs which are stored as a "system.posix_acl_access" attribute? My 
concern would be that files copied from the guest to the host wouldn't have sensible 
permissions when read directly on the host. Presumably there would be some existing 
precedent for how this is handled in WSL2?


ATB,

Mark.