]> xenbits.xensource.com Git - xen.git/commitdiff
libxl/depriv: Remove RLIMIT_NPROC restriction
authorGeorge Dunlap <george.dunlap@citrix.com>
Mon, 12 Nov 2018 11:24:54 +0000 (11:24 +0000)
committerWei Liu <wei.liu2@citrix.com>
Mon, 12 Nov 2018 11:32:27 +0000 (11:32 +0000)
This also prevents QEMU from creating pthreads, which it requires for
certain devices to function.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
docs/designs/qemu-deprivilege.md
tools/libxl/libxl_linux.c

index 067cf2476277d079dadc8e6d80b4810552f93966..f7444a434d615e6bf3724e8ca0fe647766766a99 100644 (file)
@@ -114,7 +114,6 @@ resources available to it.
 
 Limits that can be implemented immediately without much effort:
  - RLIMIT_FSIZE` (file size) to 256KiB.
- - RLIMIT_NPROC (after uid changes to a unique uid)
 
 Probably not necessary but why not:
  - RLIMIT_CORE: 0
@@ -142,6 +141,9 @@ virtual memory which QEMU uses as a mapcache.  xen-mapcache.c already
 fiddles with this; it would be straightforward to make it *set* the
 rlimit to what it thinks a sensible limit is.
 
+RLIMIT_NPROC limits total number of processes or threads.  QEMU uses
+threads for some devices, so this would require some thought.
+
 Other things that would take some cleverness / changes to QEMU to
 utilize due to ordering constrants:
  - RLIMIT_NOFILES (after all necessary files are opened)
index 921051c0e63db16653ed65c340372f72141467f1..6475cca64b9df62a43c00de8e6265afed8a3a6c8 100644 (file)
@@ -318,7 +318,6 @@ static struct {
     RLIMIT_ENTRY(RLIMIT_FSIZE,    256*1024),
 
     /* Shouldn't need any of these */
-    RLIMIT_ENTRY(RLIMIT_NPROC,    0),
     RLIMIT_ENTRY(RLIMIT_CORE,     0),
     RLIMIT_ENTRY(RLIMIT_MSGQUEUE, 0),
     RLIMIT_ENTRY(RLIMIT_LOCKS,    0),