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

[Eric Blake]

On 09/20/2012 07:31 AM, Marcelo Cerri wrote:
>>> 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),

>> 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.

The coreutils' solution in chown is that a name parse is attempted
before numeric parse, and that a leading '+' (which is not valid in
names) is the way to force a numeric parse.  If anything, we should copy
that approach for consistency.

>>> 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.

You still didn't answer my bigger question - when migrating, do we care
about the case where the same user name has different uid on the two
machines, and if so, do we make it possible for the user to choose
between migrating with constant uid vs. migrating with constant name?
If we always parse names into uids up front, then we are preventing the
user from migration by name.

-- 
Eric Blake   eblake at 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: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120920/38d00510/attachment-0001.sig>