On Thu, Apr 22, 2010 at 08:43:37AM +0200, Harald Dunkel wrote: > On 04/21/10 20:24, Spencer Shimko wrote: > > Harald Dunkel wrote: > >> > >> Do you think it would be possible to introduce a configure > >> option '--with-dac=no'? > > > > I think that would be a little misleading ;) It sounds like part of the > > problem was that the error message wasn't clearly conveying the reason > > for the problem. It wasn't an SELinux security context that was causing > > issues, it was DAC user/group. I just submitted a patch to clarify the > > error message to reference user/group instead of "security context." > > > > The error message was just an indication that there is something > fishy. All the NFS clients in my net have different UIDs and GIDs > for the local system accounts, esp. for libvirt and kvm. Sorry to > say, but the problem is not solved yet. This is unfixably broken then. NFS security relies on all clients using the same UID/GID <-> name mappings. > Questions: > > Why should libvirt have the privilege to change UID and GID of a > disk image file on an NFS server? Usually this file is -rw------- > for root. Doesn't the chown() to a UID != 0 weaken the security? QEMU itself runs as a 'qemu' user & group ID. If the disk image file is root:root -rw-------, then QEMU won't be able to read/write the image. libvirt changes the ownership to match that required for QEMU to access the disks configured in its XML. This approach increases security, because we know that QEMU will not be able to write to any files except those which have explicitly had their ownership set to 'qemu:qemu'. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list