Re: [libvirt] [PATCH v2] storage: support all file permissions
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)