On 08/07/2012 08:39 PM, Laine Stump wrote: >>> 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. Reporting the values is always safe (and might be useful for someone to realize that 'gasp, my disk.img is setuid!'), but I agree that we are setting ourselves up for problems if we allow setting the bits on all file types. Then again, we are not in the business of creating executable storage volumes, so setuid on a non-executable may be a non-issue, and for directories, the story is a bit different, as the extra bits become useful for controlling default permissions used when creating new contents. Maybe we need to compromise based on what type of file (directory vs. other) is involved? > 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). That's a good point - config should only output the bits that we will allow to be changed, and live can show all existing bits. > > 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 :-) I'm 50-50 on whether to error out, but whatever policy we settle on, we should _definitely_ document it in the corresponding docs/*.html.in files where the fields are exposed. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list