unexpected errors using lxc-usernsexec

[smoser]

Required information

• Distribution: ubuntu
• Distribution version: bionic/focal

Issue description

I am running into some issues using lxc-usernsexec. The data is collected from a fresh ubuntu cloud image with lxc-utils installed. The '+git' versions are as installed from
ppa:ubuntu-lxc/lxc-git-master.

In all cases:

• the command executed is lxc-usernsexec [-margs] -- /bin/true

• subuid/subgid are as shown:

  $ cat /etc/subuid
  lxd:100000:65536
  root:100000:65536
  ubuntu:165536:65536
  
  $ cat /etc/subgid
  lxd:100000:65536
  root:100000:65536
  ubuntu:165536:65536
  

I've attached nsuser-test and full 'DEBUG=1'
results.txt

The 2 largest issues to me are

1. focal "B..." failure:

   $ lxc-usernsexec -mb:0:1000:1 -- /bin/true
   cmd/lxc_usernsexec.c: 64: opentty - No such file or directory - Failed to open tty
   cmd/lxc_usernsexec.c: 64: opentty - No such file or directory - Failed to open tty
   lxc 20200519171528.674 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
   

2. bionic "default" failure (although this is fixed upstream, so not as big a deal):

   $ lxc-usernsexec -- /bin/true
   Failed to find subuid or subgid allocation
   

The table summarizes the results (.=PASS X=FAIL)

shortname	b	bgit	f	fgit	-margs
default	X	.	.	.
U...	X	X	X	X	-mu:0:1000:1
UG..	.	.	X	X	-mu:0:1000:1 -mg:0:1000:1
.G..	X	X	X	X	-mg:0:1000:1
UGu.	.	.	X	X	-mu:0:1000:1 -mg:0:1000:1 -mu:1:165536:1
UG.g	.	.	.	.	-mu:0:1000:1 -mg:0:1000:1 -mg:1:165536:1
UGug	.	.	.	.	-mu:0:1000:1 -mg:0:1000:1 -mu:1:165536:1 -mg:1:165536:1
B...	.	.	X	X	-mb:0:1000:1
B.b.	.	.	.	.	-mb:0:1000:1 -mb:1:165536:1

[stgraber]

@brauner

[brauner]

@smoser, try #3422 please.

[smoser]

@brauner did you try my attached test case?

I know there is a lot of output, but I would expect

• PASS for UG.., UGu., B...
• maybe PASS on U... . Its not clear to me what is expected to happen if I do not map in any group and only the current uid.

I built a debian package with fbe48de installed and then tested

$ dpkg -S `which lxc-usernsexec`
lxc-utils: /usr/bin/lxc-usernsexec
smoser@crabapple:~/src/lxc$ dpkg-query --show lxc-utils
lxc-utils	1:4.0.0-193-gfbe48de4-0smoser1

Here is the output I'm seeing now. It has the same PASS/FAIL results as
before, but reduced ERROR messages:

$ DEBUG=1 /tmp/nsuser-test.txt 
uid=1000 gid=1000 name=smoser subuid=100000 subgid=100000
ver=1:4.0.0-193-gfbe48de4-0smoser1
lxc-utils=1:4.0.0-193-gfbe48de4-0smoser1 kver=5.4.0-29-generic
----
default  PASS [0] lxc-usernsexec -- /bin/true
U...     FAIL [1] lxc-usernsexec -mu:0:1000:1 -- /bin/true
 | lxc 20200520162402.554 ERROR    conf - conf.c:lxc_map_ids:2816 - newgidmap
failed to write mapping "newgidmap: write to gid_map failed: Invalid argument": newgidmap 2218056
 | Failed to write id mapping for child process
 | lxc 20200520162402.554 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
UG..     FAIL [1] lxc-usernsexec -mu:0:1000:1 -mg:0:1000:1 -- /bin/true
 | lxc 20200520162402.563 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
.G..     FAIL [1] lxc-usernsexec -mg:0:1000:1 -- /bin/true
 | lxc 20200520162402.570 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
UGu.     FAIL [1] lxc-usernsexec -mu:0:1000:1 -mg:0:1000:1 -mu:1:100000:1 -- /bin/true
 | lxc 20200520162402.578 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
UG.g     PASS [0] lxc-usernsexec -mu:0:1000:1 -mg:0:1000:1 -mg:1:100000:1 -- /bin/true
UGug     PASS [0] lxc-usernsexec -mu:0:1000:1 -mg:0:1000:1 -mu:1:100000:1 -mg:1:100000:1 -- /bin/true
B...     FAIL [1] lxc-usernsexec -mb:0:1000:1 -- /bin/true
 | lxc 20200520162402.603 ERROR    utils - utils.c:lxc_setgroups:1363 - Operation not permitted - Failed to setgroups()
B.b.     PASS [0] lxc-usernsexec -mb:0:1000:1 -mb:1:100000:1 -- /bin/true

[smoser]

#3428 added a test derived from the tests above.

[mihalicyn]

Fixed by #3422 ?

Closed for now.