[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/9] libxl: Get rid of support for QEMU_USER_BASE (xen-qemuuser-domidNN)

  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Wed, 28 Nov 2018 17:02:30 +0000
  • Accept-language: en-GB, en-US
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
  • Delivery-date: Wed, 28 Nov 2018 17:03:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHUg1AYnwnmx0K+u0qV0+nXGTiElKVlWTEAgAAHtgA=
  • Thread-topic: [PATCH 3/9] libxl: Get rid of support for QEMU_USER_BASE (xen-qemuuser-domidNN)

> On Nov 28, 2018, at 4:34 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> George Dunlap writes ("[PATCH 3/9] libxl: Get rid of support for 
> QEMU_USER_BASE (xen-qemuuser-domidNN)"):
>> QEMU_USER_BASE allows a user to specify the UID to use when running
>> the devicemodel for a specific domain number.  Unfortunately, this is
>> not really practical: It requires nearly 32,000 entries in
>> /etc/passwd.  QEMU_USER_RANGE_BASE is much more practical.
> Is the presence of this code causing a problem ?  I am happy to
> declare it unsupported.
> I provided it because the behaviour of choosing a uid which has *no*
> passwd entry might reasonably be regarded as anomalous and
> undesirable.
> I have used systems with O(32k) password file entries for real
> users…

With QEMU_USER_BASE, there are 5 qemu uid cases to consider (root, 
 Having one less just simplifies the thinking and the logic.  Since I 
considered QEMU_USER_BASE to be impractical, I thought rather than spend time 
reasoning about it, I’d just delete it.

I’d personally just as soon leave it out (and add it back in if someone asks 
for it), but if you think it has value I can leave it in and do the work of 
thinking about the logic.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.