[libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

[Eric Blake]

On 02/27/2013 02:25 AM, Michal Privoznik wrote:
>> Are you really planning on storing a string uid:gid?  Wouldn't it be
>> simpler to store a uid_t and gid_t as read from struct stat, as long as
>> the data is only in memory?  And when storing the data to disk in XML to
>> survive libvirtd restarts, it seems like storing two attributes
>> user='nnn' group='nnn' is nicer than storing one attribute
>> owner='+nnn:+nnn' that requires further parsing back into user and group.
> 
> My idea is; store userName:groupName whenever possible; When one of them
> is not accessible, use +NNN instead. The rationale is - whenever a user
> or a gropu changes its ID, we will follow it. For instance, a file X has
> owner A:B (1:1) but libvirt chowns to C:D. Meanwhile A's ID is changed
> from 1 to 2. So when relabeling we should chown to 2:1 instead of 1:1 as
> A's ID is 2 not 1. That means I have to do parsing and all the
> virAsprintf magic. However, maybe this is not what we want and I should
> really remember just numeric values of IDs which has nice tradeoff -
> much simpler code.

Migration and shared storage makes this problem so much tougher - the
uid on shared storage is common, but the name is not necessarily common.
 I'd go for uid only; leave name lookups to each local machine
connecting to shared storage, but don't store the name ourselves.
Besides, admins tend not to change the name associated with a uid all
that frequently (it's generally one-time setup).

Dan has a point that you really need to involve the lock manager or use
some persistent storage (extended attribute or additional file in the
storage pool) alongside the file whose attributes we want to remember -
if a file is on shared storage, then it is the responsibility of the
last machine using the image to restore permissions, even if it was not
the machine that first did a chmod().  Merely storing a hash in just a
single libvirtd instance won't scale.  Does our virlockd interface
support attaching attributes to a file as part of locking it?

>> How is this information is preserved across a libvirtd restart?  You'll
>> need code that outputs private XML on the save side, then parses it back
>> on the load side - is that later in the series?
>>
> 
> Yes. That is what the next two patches do. Moreover, the design may look
> slightly like an overkill for now, but it is just for easier
> implementation for migrating the internal state of security driver.

I'm not quite sure I follow your plans for migration of security driver
state.  We migrate domains, not drivers - but you are storing persistent
attributes on a driver, not per-domain state.

-- 
Eric Blake   eblake 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: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130227/3e59cd9a/attachment-0001.sig>