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

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(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org