On 08/07/2012 10:40 AM, Dave Allan wrote: > On Tue, Aug 07, 2012 at 10:27:15AM +0200, Ján Tomko wrote: >> On 08/07/12 07:17, Laine Stump wrote: >>> On 07/26/2012 04:52 AM, Ján Tomko wrote: >>>> sticky, setuid and setgid are no longer ignored. >>> I'm always automatically wary of any code that allows setting the suid >>> bit, in case it may allow some new security hole. I can't think of >>> anything specific that could be allowed by setting the suid bit of a >>> directory containing a disk image, but then again I haven't thought >>> about it very hard :-) Can anyone convince me one way or the other? >> SUID on directories is ignored on most systems, but you could be able to >> create files belonging a group you're not a member of. >> >> But this patch enables it on files too, allowing everyone with access to >> privileged libvirtd to create SUID files. I don't know if it's possible >> to exploit this, but I don't like it, so NACK NACK NACK. >> >>> It might help to learn why you want to be able to set these bits. >>> libvirt is generally very specific about explicitly setting the uid of >>> disk images properly as required at runtime... >> My issue was that vol-dumpxml reported wrong file permissions, as >> described in https://bugzilla.redhat.com/show_bug.cgi?id=839463 >> >> Writing the sticky bit seems harmless to me. Yeah, I think I agree with that. (Heh - I'd never read the history of the sticky bit before (i.e. where it got the name "sticky") - "retain the text segment <http://en.wikipedia.org/wiki/Text_segment> of the program in swap space <http://en.wikipedia.org/wiki/Virtual_memory> after the process <http://en.wikipedia.org/wiki/Process_%28computing%29> exited". Remember when loading the text segment of a program took long enough for that to matter?) >> Would it be safe to just >> read SGID and SUID without ever setting them? Or is it not worth the risk? > IMO we should preserve the existing behavior of not modifying the > bits, but we should report them correctly, although I don't feel all > that strongly about it. > That sounds reasonable to me, as long as the reported difference only shows up during a dumpxml of the "live" XML (and not during a pool-dumpxml --inactive). I'm wondering if we should generate an error when someone tries to specify those bits in a pool-define (and vol-define), or just ignore them as we currently do. (no opinion, just wondering :-) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list