User account required for creating LXC container

(Tommy C. Lee) #1

Hi LXC members,

I just started my LXC work on an ARM Cortex-A9 based embedded Linux platform. The kernel version is 3.0.35. The LXC version is 0.7.5.

My first queastion is whether LXC needs a user registration which is different from root. On my platofrm there is only one user registration -root. The reason for this question is that I am wondering if I need to use the usermod command to create my own /etc/subuid and /etc/subgid files.

I wish you could answer my question.



LXC containers can belong to root and be run as root, no problem.

You can even run unprivileged containers as root, but then the root user needs to have SUBUID and SUBGID ranges assigned. You can assign those with usermod (or editing /etc/subuid and /etc/subgid by hand, if you’re so inclined).

If there are no SUBUID/SUBGID entries for root in those files, then containers created by root will be privileged. This works perfectly well, but it’s inherently less secure, since a process in the container that somehow manages to escape it, then runs as root on the host.

With an unprivileged container, such a process would have a very high UID on the host, which is unassigned there, so it effectively runs as user nobody on the host.

(Tommy C. Lee) #3


Thanks for your experience sharing.

For the security reason my choice is the unpriviledged. I just edited my /etc/subuid and /etc/subgid files as:

root@phyFLEX-i:~ egrep lxc /etc/sub*

Now I am finding out the package which has usermod command in it. I think I need it to add “lxc” as the unpriledged container owner. If you know the package please tell me.



Alright, so there’s some confusion here, especially around unprivileged containers. I thought I had made it clear in my first answer, but maybe not, so I’ll try again:

  1. Users
    You can run unprivileged containers as a dedicated user, but you don’t have to. You can also run them as root. AFAIK running an unprivileged container as root is not less secure than having a dedicated user for it.

  2. SUBUID/SUBGID ranges
    Whichever user you decide to use for the container(s) needs to exist and have entries in /etc/subuid and /etc/subgid. The ranges for different users and groups must not overlap and the lowest range must start above the highest UID or GID you expect to use on the host.

  3. usermod
    Since you already edited /etc/subuid and /etc/subgid by hand, you don’t need to use usermod anymore. You may still use it, however, e.g. to add SUBUID/SUBGID ranges for root.

  4. Your /etc/sub[ug]id files
    Your entries are probably fine, although
    a. they are for a user named lxc, who must of course exist on the system.
    b. to check that the ranges don’t overlap, one would have to see the full contents

  5. Required package
    Which package usermod is in probably depends on the distribution you use. On Debian and derived distros (like Ubuntu or Mint) it*s in the package passwd. This package also contains the useradd command which you might want to use to actually add the user to lxc to your system (if you decide to use a dedicated user).

I hope this clears it up a bit.

(Tommy C. Lee) #5


Thanks for your reply again! Please view my in-line reply.



Hi Tommy,

I’m afraid I cannot see your reply. Could you try submitting it again, please?


(Tommy C. Lee) #7


I am sending you my reply again. Please tell me whether you ar able to view it.


(Tommy C. Lee) #8


While I am building my useradd command, my team member has three more questions:

  1. Whether a template needs to be created from scratch for every particular container?
  2. Whether the root user should be used as the owner of multiple containers?
  3. What are the pre-requisites to start a newly created container?

I wish you would like to answer their questions.



No, multiple independent containers may be created from the same template. (Hence, why it’s called “template”)

It’s up to you. root may own multiple containers, whether she should is your decision.

None, once it’s created, AFAIK.

You should probably run lxc-checkconfig before you create containers, to see whether your kernel has all of the necessary features enabled.

After container creation, just run lxc-start -n <name of container> and it should run. You can check this with lxc-info -n <name of container> and attach (i.e. open a shell session as root within then container) with lxc-attach -n <name of container>.

If it doesn’t work:

  • consult documentation on how to enable logging
  • (try to) start container with debug logging enabled
  • look into the logfile and
  • search the web for the error messages.

(Tommy C. Lee) #10


I am building the useradd program now. But I am wondering if I need this program in the situation where the root user can own multiple containers.


(Tommy C. Lee) #11


Temporarily putting the useradd program building work aside, on my target platform I did the following steps as you mentioned. The “lxc-attach -n femtolxc” execution ends up with failures. Listed below is what I have so far.

I am resolving the failure. Your comment is absolutely welcome.

root@phyFLEX-i:~ lxc-checkconfig
— Namespaces —
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

— Control groups —
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

— Misc —
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: missing

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
root@phyFLEX-i:~ lxc-create -n femtolxc
’femtolxc’ created
root@phyFLEX-i:~ lxc-start -n femtolxc
root@phyFLEX-i:~ lxc-info -n femtolxc
state: RUNNING
pid: 3510
root@phyFLEX-i:~ lxc-attach -n femtolxc
lxc-attach: No such file or directory - failed to open '/proc/3510/ns/pid’
lxc-attach: failed to enter the namespace


I’m a bit out of my depth here, I’m afraid.

It looks like there’s a problem accessing the container’s main process’ PID namespace. It should be found under /proc/${PID}/ns/pid, where ${PID} is the PID of the container’s main process (usually init or systemd) as shown by lxc-info.

I have no idea, why that (pseudo) file should be missing and what could cause that, especially since the output from lxc-checkconfig shows that PID namespaces are enabled in your kernel.

Maybe you could show the contents of /proc/${PID}/ns/, if it exists, or - if it doesn’t - the contents of /proc/${PID}/`. And I hope that someone with more of a clue than me can have a look at this, too.

(Tommy C. Lee) #13


Listed below is the /proc/14576/ns.
root@phyFLEX-i:~ ls -lrt /proc/14576/ns
-r-------- 1 root root 0 Feb 6 13:25 uts
-r-------- 1 root root 0 Feb 6 13:25 net
-r-------- 1 root root 0 Feb 6 13:25 ipc

The previous “lxc-info -n f1” command shows that the container’s PID is 14576. The “ps uax|egrep systemd” execution shows:

root@phyFLEX-i:~ ps uax|egrep systemd
root 1882 0.0 0.0 2020 456 ? Ss 09:08 0:00 /lib/systemd/systemd-stdout-syslog-bridge
root 2469 0.0 0.0 2600 1008 ? Ss 09:08 0:00 /lib/systemd/systemd-logind
103 2483 0.0 0.0 2352 1120 ? Ss 09:08 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
root 15050 0.0 0.0 2020 460 ? Ss 13:21 0:00 /lib/systemd/systemd-stdout-syslog-bridge
root 15724 0.0 0.0 2600 1048 ? Ss 13:21 0:00 /lib/systemd/systemd-logind
103 15732 0.0 0.0 2352 1124 ? Ss 13:21 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
root 16064 0.0 0.0 2124 380 pts/4 S+ 13:30 0:00 egrep systemd

I need to do a research on the result to resolve this failure.


(Stéphane Graber) #14

So this is LXC 0.7.5 with a 3.0.35 kernel. Meaning a severely outdated version of LXC which is entirely unsupported with a similarly outdated kernel which I doubt anyone still supports.

For your initial question, that version of LXC should be fine if used by the root user.

/etc/subuid and /etc/subgid are only relevant if running LXC as non-root, but for that to even be an option, you’d need LXC 1.0 or higher and a 3.13 kernel or higher. Since you don’t have either of those things, then just stick to privileged containers run by the root user.

lxc-attach also won’t work with such an old kernel, you need a 3.8 kernel or higher for it to be possible to attach to the pid namepsace.