Re: [libvirt] [PATCH] security: also parse user/group names instead of just IDs for DAC labels
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