On Thu, Jun 27, 2013 at 05:31:04PM +0200, Michal Privoznik wrote: > Dear list, > > it's been a while since I've tried to get the patches in [1]. > However, it turned out that we need completely different approach. Now > I'd like to revisit that decision. > > The problem is: libvirt sets various security labels (DAC, selinux) in > order for a file to be readable by a qemu process. However, it doesn't > record the original labels, so in process of tearing the domain down, we > restore "defaults" (in case of DAC we set root:root instead of > john:doe). Moreover, if a file is to be shared among multiple domains we > can't restore the label as it would make it inaccessible for other qemu > processes. > > My implementation dealt with this problem using XATTRs: one to store the > original label, the other one as a reference counter. For each labeling > the counter is increased. For each attempt to restore the label the > counter is decreased. The original label is restored iff the counter is > zero. However, this approach doesn't work well with two libvirtd > instances fighting over a file. But one can argue that this is something > for cluster. The question is - do we want to reimplement cluster in libvirt? > > I think my approach seems like reasonable trade-off. So what's your > opinion on this? We already have to solve this type of problem in libvirt for ensuring exclusive access to disk by concurrently started QEMUs from different libvirtds. To protect relabelling code, we should just need to have the security drivers talk to virtlockd to protect their critical sections against races. So I think we can & should do the right thing here. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list