Lvl=info msg="LXD 2.14 is starting in normal mode" path=/var/lib/lxd t=T21:21:13+0000 I tend to bump it to a billion just so I don’t ever have to think about it again: cat cat /etc/subgidĪfter altering those files, you need to restart LXD to have it detect the new map: systemctl restart cat /var/log/lxd/lxd.log Simply edit both of the files and bump the last value from 65536 to whatever size you need. Now if you want to increase the size of the map available to LXD. The “lxd” entry is used to track what needs to be removed if LXD is uninstalled.
LXD itself is restricted by the “root” allocation. The maps for “lxd” and “root” should always be kept in sync. LXD will assume that it doesn’t have to share uid/gid ranges with anything else and will therefore assume control of a billion uids and gids, starting at the host uid/gid 100000.īut the common case, is a system with a recent version of shadow.Īn example of what the configuration may look like is: cat cat /etc/subgid
On systems that do not have a recent enough version of the “shadow” package. On systems where that’s the case, the “/etc/subuid” and “/etc/subgid” files are used to configure those maps.
The default map is usually controlled by the “shadow” set of utilities and files.
You want to punch some holes in your container’s map and need access to host uids/gids. In which case you’ll need 65536 available uid/gid per container. This is most common when using network authentication inside of your containers. You need access to uid/gid higher than 65535. There are however a few cases where you may have to: In most cases you won’t have to change that. Punching holes into the map to expose host users and groupsĪs mentioned above, in most cases, LXD will have a default map that’s made of 65536 uids/gids. Increasing the size of the default uid/gid map. LXD does offer a number of options related to unprivileged configuration: It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them.įrom a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level). As you may know, LXD uses unprivileged containers by default.
0 kommentar(er)
