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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list