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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Freitag, 8. April 2022 17:00:59 CEST Greg Kurz wrote:
> 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().

+Akihiko on CC.

Like always when it comes to POSIX APIs, Apple's documentation on this is far 
from being great. I actually had to test out what's supported with mknod() on 
macOS, in which way, and what is not (tested on macOS 12 "Monterey" only):

* S_IFIFO: works, even as regular user.

* S_IFREG: doesn't work, neither as regular user (ERRNO 1, Operation not 
  permitted), nor as super-user (ERRNO 22, Invalid argument). So we should 
  divert that to a regular open() call on macOS.

* S_IFCHR and S_IFBLK: works as super-user, doesn't work for regular user 
  (ERRNO 1, Operation not permitted). So if 9p is used with passthrough 
  permissions, we should probably stick to the direct mknod() call and that 
  the user would need to run QEMU as super-user to get this working. Whereas 
  if 9p is used with mapped permissions, we should fake those devices by 
  creating regular files, store their type and major, minor numbers there and 
  that's it. We don't expect that guest ever tries to read/write such block/
  character devices, right? I.e. I'm assuming that any read/write is handled 
  as an overlay by Linux kernel on its guest level, correct?

* S_IFSOCK: doesn't work, neither as regular user (ERRNO 1, Operation not 
  permitted), nor as super-user (ERRNO 22, Invalid argument). So we should 
  divert that to a socket() call on macOS.

Thoughts?

Best regards,
Christian Schoenebeck