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

[Greg Kurz]

On Fri, 08 Apr 2022 15:52:25 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> 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?
> 

I'd rather keep that for the mapped security mode only to avoid
confusion, but qemu_mknodat() is also used in passthrough mode.

Anyway, it seems that macOS's mknod() only creates device files,
unlike linux (POSIX) which is also used to create FIFOs, sockets
and regular files. And it also requires elevated privileges,
CAP_MKNOD, in order to create device files.

It seems that this implementation of qemu_mknodat() is just missing
some features that can be implemented with unprivileged syscalls like
mkfifo(), socket() and open().

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