> I agree, regardless of libvirt's needs, p9fs needs to be secure for any
> non-root user using QEMU. As non-root I should be able todo
>
> $ qemu -virtfs $HOME/shared
>
> and have strong confidence that symlink attacks can't be used by the
> guest to access other locations nuder $HOME.
>
> > A virtfs feature that needs root therefore needs to be in a separate
> > process. Either QEMU needs to fork or virtfs could use a separate
> > daemon binary.
>
> One other idea I just had is 'fakechroot'. This is basically an LD_PRELOAD
> hack which wraps the C library's native chroot(), open() etc call to do
> chroot in userspace, thus avoiding a need for root privileges.
>
> Either you could just invoke QEMU via fakechroot, enabling your code from
> these patches to be used as non-root. Or we could take the code from the
> fakechroot library and use that directly in the p9fs code to apply the
> path security checks
>
With fakechroot is that I can still do following:
chroot("/etc/cups");
fd = open("../passwd", O_RDONLY);
It does not check access beyond the chroot path. Also in virtio-9p case, a
modified guest kernel can send a symbolic link and that could resolve outside
chroot path.
passthrough security model in virtio-9p needs root privilege not only for
chroot() syscall but also to do chown and chmod on files created by the guest.
So IMHO fakechroot can't be used in this case.
