Gecko [ www.jdcpatala.org ]

Name	Size	Permission
explanation	[ DIR ]	drwxr-xr-x
howto	[ DIR ]	drwxr-xr-x
reference	[ DIR ]	drwxr-xr-x
tutorial	[ DIR ]	drwxr-xr-x
api-extensions.md.txt	108.13 KB	-rw-r--r--
api.md.txt	886 B	-rw-r--r--
architectures.md.txt	2.14 KB	-rw-r--r--
authentication.md.txt	11.86 KB	-rw-r--r--
backup.md.txt	6.08 KB	-rw-r--r--
cloud-init.md.txt	13.2 KB	-rw-r--r--
clustering.md.txt	1.45 KB	-rw-r--r--
config-options.md.txt	194 B	-rw-r--r--
container-environment.md.txt	3.2 KB	-rw-r--r--
contributing.md.txt	7.48 KB	-rw-r--r--
daemon-behavior.md.txt	1.2 KB	-rw-r--r--
database.md.txt	1.74 KB	-rw-r--r--
debugging.md.txt	6.34 KB	-rw-r--r--
dev-lxd.md.txt	5.06 KB	-rw-r--r--
doc-cheat-sheet-myst.md.txt	4.15 KB	-rw-r--r--
environment.md.txt	2.48 KB	-rw-r--r--
events.md.txt	25.55 KB	-rw-r--r--
faq.md.txt	7.4 KB	-rw-r--r--
getting_started.md.txt	1.93 KB	-rw-r--r--
guest-os-compatibility.md.txt	7.31 KB	-rw-r--r--
image-handling.md.txt	3.93 KB	-rw-r--r--
images.md.txt	1003 B	-rw-r--r--
index.md.txt	3.45 KB	-rw-r--r--
installing.md.txt	14.52 KB	-rw-r--r--
instance-exec.md.txt	8.96 KB	-rw-r--r--
instances.md.txt	2.42 KB	-rw-r--r--
internals.md.txt	727 B	-rw-r--r--
metrics.md.txt	13.74 KB	-rw-r--r--
networks.md.txt	2.06 KB	-rw-r--r--
operation.md.txt	1.09 KB	-rw-r--r--
production-setup.md.txt	1.35 KB	-rw-r--r--
profiles.md.txt	9.96 KB	-rw-r--r--
projects.md.txt	823 B	-rw-r--r--
remotes.md.txt	3.17 KB	-rw-r--r--
requirements.md.txt	2.2 KB	-rw-r--r--
rest-api.md.txt	9.03 KB	-rw-r--r--
restapi_landing.md.txt	385 B	-rw-r--r--
server.md.txt	3.06 KB	-rw-r--r--
storage.md.txt	1.26 KB	-rw-r--r--
support.md.txt	2.23 KB	-rw-r--r--
syscall-interception.md.txt	5.34 KB	-rw-r--r--
userns-idmap.md.txt	3.72 KB	-rw-r--r--

Code Editor : userns-idmap.md.txt

# Idmaps for user namespace

LXD runs safe containers. This is achieved mostly through the use of
user namespaces which make it possible to run containers unprivileged,
greatly limiting the attack surface.

User namespaces work by mapping a set of UIDs and GIDs on the host to a
set of UIDs and GIDs in the container.

For example, we can define that the host UIDs and GIDs from 100000 to
165535 may be used by LXD and should be mapped to UID/GID 0 through
65535 in the container.

As a result a process running as UID 0 in the container will actually be
running as UID 100000.

Allocations should always be of at least 65536 UIDs and GIDs to cover
the POSIX range including root (0) and nobody (65534).

## Kernel support

User namespaces require a kernel >= 3.12, LXD will start even on older
kernels but will refuse to start containers.

## Allowed ranges

On most hosts, LXD will check `/etc/subuid` and `/etc/subgid` for
allocations for the `lxd` user and on first start, set the default
profile to use the first 65536 UIDs and GIDs from that range.

If the range is shorter than 65536 (which includes no range at all),
then LXD will fail to create or start any container until this is corrected.

If some but not all of `/etc/subuid`, `/etc/subgid`, `newuidmap` (path lookup)
and `newgidmap` (path lookup) can be found on the system, LXD will fail
the startup of any container until this is corrected as this shows a
broken shadow setup.

If none of those files can be found, then LXD will assume a 1000000000
UID/GID range starting at a base UID/GID of 1000000.

This is the most common case and is usually the recommended setup when
not running on a system which also hosts fully unprivileged containers
(where the container runtime itself runs as a user).

## Varying ranges between hosts

The source map is sent when moving containers between hosts so that they
can be remapped on the receiving host.

## Different idmaps per container

LXD supports using different idmaps per container, to further isolate
containers from each other. This is controlled with two per-container
configuration keys, {config:option}`instance-security:security.idmap.isolated` and {config:option}`instance-security:security.idmap.size`.

Containers with `security.idmap.isolated` will have a unique ID range computed
for them among the other containers with `security.idmap.isolated` set (if none
is available, setting this key will simply fail).

Containers with `security.idmap.size` set will have their ID range set to this
size. Isolated containers without this property set default to a ID range of
size 65536; this allows for POSIX compliance and a `nobody` user inside the
container.

To select a specific map, the `security.idmap.base` key will let you
override the auto-detection mechanism and tell LXD what host UID/GID you
want to use as the base for the container.

These properties require a container reboot to take effect.

## Custom idmaps

LXD also supports customizing bits of the idmap, e.g. to allow users to bind
mount parts of the host's file system into a container without the need for any
UID-shifting file system. The per-container configuration key for this is
{config:option}`instance-raw:raw.idmap`, and looks like:

both 1000 1000
    uid 50-60 500-510
    gid 100000-110000 10000-20000

The first line configures both the UID and GID 1000 on the host to map to UID
1000 inside the container (this can be used for example to bind mount a user's
home directory into a container).

The second and third lines map only the UID or GID ranges into the container,
respectively. The second entry per line is the source ID, i.e. the ID on the
host, and the third entry is the range inside the container. These ranges must
be the same size.

This property requires a container reboot to take effect.

${this.title}

Code Editor : userns-idmap.md.txt