Re: [PATCH v9 09/11] 9p: darwin: Implement compatibility for mknodat

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Sonntag, 27. Februar 2022 23:35:20 CEST Will Cohen wrote:
> From: Keno Fischer <keno@juliacomputing.com>
> 
> Darwin does not support mknodat. However, to avoid race conditions
> with later setting the permissions, we must avoid using mknod on
> the full path instead. We could try to fchdir, but that would cause
> problems if multiple threads try to call mknodat at the same time.
> However, luckily there is a solution: Darwin includes a function
> that sets the cwd for the current thread only.
> This should suffice to use mknod safely.
[...]
> diff --git a/hw/9pfs/9p-util-darwin.c b/hw/9pfs/9p-util-darwin.c
> index cdb4c9e24c..bec0253474 100644
> --- a/hw/9pfs/9p-util-darwin.c
> +++ b/hw/9pfs/9p-util-darwin.c
> @@ -7,6 +7,8 @@
> 
>  #include "qemu/osdep.h"
>  #include "qemu/xattr.h"
> +#include "qapi/error.h"
> +#include "qemu/error-report.h"
>  #include "9p-util.h"
> 
>  ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char
> *name, @@ -62,3 +64,34 @@ int fsetxattrat_nofollow(int dirfd, const char
> *filename, const char *name, close_preserve_errno(fd);
>      return ret;
>  }
> +
> +/*
> + * As long as mknodat is not available on macOS, this workaround
> + * using pthread_fchdir_np is needed.
> + *
> + * Radar filed with Apple for implementing mknodat:
> + * rdar://FB9862426 (https://openradar.appspot.com/FB9862426)
> + */
> +#if defined CONFIG_PTHREAD_FCHDIR_NP
> +
> +int qemu_mknodat(int dirfd, const char *filename, mode_t mode, dev_t dev)
> +{
> +    int preserved_errno, err;
> +    if (!pthread_fchdir_np) {
> +        error_report_once("pthread_fchdir_np() not available on this
> version of macOS"); +        return -ENOTSUP;
> +    }
> +    if (pthread_fchdir_np(dirfd) < 0) {
> +        return -1;
> +    }
> +    err = mknod(filename, mode, dev);

I just tested this on macOS Monterey and realized mknod() seems to require 
admin privileges on macOS to work. So if you run QEMU as ordinary user on 
macOS then mknod() would fail with errno=1 (Operation not permitted).

That means a lot of stuff would simply not work on macOS, unless you really 
want to run QEMU with super user privileges, which does not sound appealing to 
me. :/

Should we introduce another fake behaviour here, i.e. remapping this on macOS 
hosts as regular file and make guest believe it would create a device, similar 
as we already do for mapped links?

> +    preserved_errno = errno;
> +    /* Stop using the thread-local cwd */
> +    pthread_fchdir_np(-1);
> +    if (err < 0) {
> +        errno = preserved_errno;
> +    }
> +    return err;
> +}
> +
> +#endif