[libvirt] [PATCH v2] storage: support all file permissions

Eric Blake eblake at redhat.com
Tue Aug 14 23:25:20 UTC 2012


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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120814/65c56c7e/attachment-0001.sig>


More information about the libvir-list mailing list