On 09/19/2012 03:32 PM, Marcelo Cerri wrote: > The DAC driver is missing parsing of group and user names for DAC labels > and currently just parses uid and gid. This patch extends it to support > names, so the following security label definition is now valid: > > <seclabel type='static' model='dac' relabel='yes'> > <label>qemu:qemu</label> > <imagelabel>qemu:qemu</imagelabel> > </seclabel> Question for migration - what if qemu is uid/gid 107 on machine A but 108 on machine B. Then it might be nice if an explicit use of <label>107:107</label> says to preserve uid (but switch effective users) on migration, while <label>qemu:qemu</label> says to preserve the user identification, in spite of the change in underlying uid. And depending on how the shared storage is accessed, such as via NFS with uid mapping, preserving user name instead of uid might actually be important. If that's true, then we need to enhance domain_conf.c to track whether the user passed in ids or names in their XML. For that matter, to avoid possible ambiguities (since it is legal [although stupid] to have a user name consisting of all digits and worse having the name differ from the underlying uid), should we have an optional attribute that gives us a hint whether the contents are intended as an id number or as a string name? That is, I wonder if we'd want something like: <label type='id'>107:107</label> <imagelabel type='name'>qemu:qemu</label> except that what happens if I want to mix number and name between uid and gid? -- 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