Privilege separation between containers

For my first LXC tests, I’ve created an “lxc” unprivileged account and “vhosts” group for it.

One key of the unprivileged account is to not be same user as root one, of course. But what about when I’m using same unprivileged account for more that one container (VPS)?

I mean that, to be sure malicious user or program from one container, it hasn’t permissions to access any to other container’s resources, I suppose I should launch each unprivileged container with a different host’s uid and gid.
Am I right?


The account that launches a LXD container is a management account rather than an account under which you run a container.

Which means, those non-root accounts that belong to the lxd group, are all equal to what they can do with LXD. This is also reflected in the LXD documentation. Such a LXD management account should be considered as an administrative account.

I’m not using LXD but LXC. I want to know:
I launch an “A” LXC container with a common account (such as “narcis”), and I launch a “B” container with same common account; in this situation: Can a guest from “A” access to “B” resources because of matching containers launcher uid?

If both containers use the same uid/gid map, it would be possible for one container to set ulimits which would affect the other. So a denial of service type attack would be possible, access to the files or other resources of the other container wouldn’t be possible though.

1 Like

This means for me that directory backing store is complex to organize:
In it says:

The rootfs for a privileged directory backed container is located (by default) under /var/lib/lxc/C1/rootfs, while the rootfs for an unprivileged container is under ~/.local/share/lxc/C1/rootfs. If a custom lxcpath is specified in, then the container rootfs will be under $lxcpath/C1/rootfs.

If I use only unprivileged containers and with one different user account per each container, with the default behaviour I would obtain this complex tree:


…adding lots of template files at:


What is the best configuration and plan to organize this in an unified tree like privileged containers have?

You can grow your allocation in /etc/subuid and /etc/subgid to be 6553*number-of-containers and then use a different default.conf file for each of them during lxc-create, so using a single user on the system but still having non-overlapping uid/gid map for each container.

This is effectively what LXD does for you when using security.idmap.isolated except it can also track what range was used and look for a free one automatically.

1 Like

About default.conf do you mean the final lxc.id_map parameter in container’s “config” file?

lxc.id_map = u 0 165536 65536
lxc.id_map = g 0 165536 65536

Yeah, you’d have this vary for every one of your containers, having that 165536 go up by 65536 every time so they all get non-overlapping ranges.

1 Like

As I understand, to share same unprivileged account name in host, it’s enough with managing wide range in /etc/subuid and each container’s lxc.id_map parameter for subranges in config file.

$ cat /etc/subuid

What if subuid beginning of another user is above unprivileged lxc account? If I know other users don’t use LXC, is everybody safe on subuid ranges being moved (or swapped)?
Where is the adduser policy configured, to set beginning subuids for new user accounts?

I mean; Can I modify same host example resulting this?

$ cat /etc/subuid

Could this affect other operating system behaviour or users behaviour?

If they don’t use subuid/subgid, you can just remove their allocation or indeed re-shuffle them.

1 Like

There seems to be a problem when using Debian Stable (buster):

Is there some limit at 500000 numbering zone?