[libvirt] [PATCH] security: also parse user/group names instead of just IDs for DAC labels

[Marcelo Cerri]

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
>