On Sun, 2020-11-01 at 14:38 +0300, Roman Bolshakov wrote: > On Wed, Oct 28, 2020 at 08:25:46PM +0100, Michal Privoznik wrote: > > One thing to consider here (and my rough googling did not help) is that we > > need the namespace to be RW only by root. If it were writable by a regular > > user (e.g "user." on linux) then a regular user could trick us to chown() > > the file to whatever user they please. Is "org" (and per your commit message > > in fact any XATTR namespace, since it doesn't look like mac os has any > > notion of namespaces after all) writable by root only? > > After investigation of xnu kernel, I've found com.apple.system namespace > that can be used to store system attributes but it can't be > set/received/listed from userspace. > > $ xattr -w com.apple.system.libvirt bar foo > xattr: [Errno 1] Operation not permitted: 'foo' > > $ sudo xattr -w com.apple.system.libvirt bar foo > xattr: [Errno 1] Operation not permitted: 'foo > > I haven't found any kind of "trusted"/"system" namespace that can be > used from user-space. Okay, so it sounds like we definitely don't want to perform owner remembering on macOS. > But I'm not sure if libvirt on macOS is going to > be used from root, rather from a user account. So, it's just qemu:///session on macOS? What happens if you try to run libvirtd as root instead? It's great that apparently the scenario that most macOS users are going to encounter works, but I'm still concerned that we might not behave reasonably when qemu:///system is tried instead... > The feature the tests exists for is: > https://patchew.org/Libvirt/cover.1544618362.git.mprivozn@xxxxxxxxxx/ > https://www.redhat.com/archives/libvir-list/2019-November/msg00862.html > > What do you think if the tests will be skipped on macOS? ... and that skipping this test would just be papering over an actual issue. -- Andrea Bolognani / Red Hat / Virtualization
