On Thu, Sep 20, 2012 at 03:00:17PM +0200, Peter Krempa wrote: > On 09/20/12 02:31, Eric Blake wrote: > >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: > > The other option (that I prefer more) would be to document this > behavior and leave it as proposed in this patch. Or maybe just > reverse the order of resolving so that the numerical parsing is done > before name parsing. > > If we warn the user, that specifying numerical values will result > into using them as UID and GID and strings being translated we > filter out the ambiguity by our design. > > I don't think it's worth spending this effort on such a weird corner case. I agree with Peter here. These ambiguities will be very rare and a well-documented behavior should be enough for this scenario. However reversing the order still can lead to ambiguities, because it's never possible to be sure if a sequence of digits is a username or not. But again, we just need to make this point clear in docs. I'll update the documentation with this in a v2 patch if you're in agreement. > > > > ><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? > > > > Mixing them will work in my approach presented here. > > > Peter > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list