Idmappings

ID 매핑의 목적

대부분의 파일시스템 개발자는 ID 매핑(idmapping)을 접하게 됩니다. ID 매핑은 디스크에서 소유권을 읽거나 디스크에 기록할 때, 소유권을 사용자 공간에 보고할 때, 그리고 권한을 검사할 때 사용됩니다.

이 문서는 ID 매핑이 어떻게 동작하는지 알고 싶은 파일시스템 개발자를 대상으로 합니다. 이후의 `u`, `k`, `v` 표기는 단순한 접두사가 아니라 각각 사용자 공간, 커널, VFS mount 관점의 ID 공간을 구분합니다.

.. SPDX-License-Identifier: GPL-2.0

Idmappings
==========

Most filesystem developers will have encountered idmappings. They are used when
reading from or writing ownership to disk, reporting ownership to userspace, or
for permission checking. This document is aimed at filesystem developers that
want to know how idmappings work.

형식 표기와 순서 동형

ID 매핑은 본질적으로 한 ID 범위를 다른 범위 또는 같은 범위로 변환하는 것입니다. 사용자 공간에서 널리 쓰는 표기는 `u:k:r`입니다. `u`는 위쪽 ID 매핑 집합 `U`의 첫 원소, `k`는 아래쪽 ID 매핑 집합 `K`의 첫 원소를 가리키며, `r`은 매핑되는 ID의 개수인 범위를 뜻합니다. 이 문서에서는 어느 집합의 ID인지 분명히 하려고 모든 ID에 `u` 또는 `k`를 붙입니다.

예를 들어 `u22:k10000:r3`은 `u22`, `u23`, `u24`를 각각 `k10000`, `k10001`, `k10002`로 대응시킵니다. 범위의 시작점은 달라도 상대적 순서는 보존됩니다.

수학적으로 `U`와 `K`는 정렬 집합(well-ordered set)이고, ID 매핑은 `U`에서 `K`로 가는 순서 동형(order isomorphism)입니다. 따라서 두 집합은 순서 동형이며, 실제로는 해당 시스템에서 사용할 수 있는 모든 ID 집합의 정렬된 부분집합입니다.

Formal notes
------------

An idmapping is essentially a translation of a range of ids into another or the
same range of ids. The notational convention for idmappings that is widely used
in userspace is::

 u:k:r

``u`` indicates the first element in the upper idmapset ``U`` and ``k``
indicates the first element in the lower idmapset ``K``. The ``r`` parameter
indicates the range of the idmapping, i.e. how many ids are mapped. From now
on, we will always prefix ids with ``u`` or ``k`` to make it clear whether
we're talking about an id in the upper or lower idmapset.

To see what this looks like in practice, let's take the following idmapping::

 u22:k10000:r3

and write down the mappings it will generate::

 u22 -> k10000
 u23 -> k10001
 u24 -> k10002

From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an
idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are
order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
the set of all possible ids usable on a given system.

역매핑과 매핑되지 않은 ID

수학적 관점은 서로 다른 ID 매핑 사이를 어떻게 변환할 수 있는지 이해하는 데 도움이 됩니다. 역 ID 매핑 역시 순서 동형이므로 앞의 예는 `k10000 -> u22`, `k10001 -> u23`, `k10002 -> u24`로 되돌릴 수 있습니다.

ID 매핑은 순서 동형인 부분집합을 다루므로 서로 끼워 넣어 합리적으로 변환할 수 있습니다. `u0:k10000:r10000`, `u0:k20000:r10000`, `u0:k30000:r10000`이 있을 때 첫 매핑의 `u1000`은 `k11000`입니다. 이를 첫 매핑의 역함수로 올리면 `u1000`이고, 둘째 또는 셋째 매핑으로 다시 내리면 각각 `k21000`, `k31000`이 됩니다.

그러나 둘째 범위가 `r200`, 셋째 범위가 `r300`이라면 두 매핑의 `U`에는 `u1000`이 없습니다. 첫 매핑의 전체 범위와 더는 순서 동형이 아니므로 변환은 실패합니다. 다만 둘째 매핑의 전체 범위에 대해서는 서로 순서 동형입니다.

이 상태를 `u1000`이 둘째와 셋째 매핑에서 매핑되지 않았다고 말합니다. 커널은 매핑되지 않은 ID를 사용자 공간에 overflowuid `(uid_t)-1` 또는 overflowgid `(gid_t)-1`로 보고합니다.

Looking at this mathematically briefly will help us highlight some properties
that make it easier to understand how we can translate between idmappings. For
example, we know that the inverse idmapping is an order isomorphism as well::

 k10000 -> u22
 k10001 -> u23
 k10002 -> u24

Given that we are dealing with order isomorphisms plus the fact that we're
dealing with subsets we can embed idmappings into each other, i.e. we can
sensibly translate between different idmappings. For example, assume we've been
given the three idmappings::

 1. u0:k10000:r10000
 2. u0:k20000:r10000
 3. u0:k30000:r10000

and id ``k11000`` which has been generated by the first idmapping by mapping
``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset.

Because we're dealing with order isomorphic subsets it is meaningful to ask
what id ``k11000`` corresponds to in the second or third idmapping. The
straightforward algorithm to use is to apply the inverse of the first idmapping,
mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
either the second idmapping mapping or third idmapping mapping. The second
idmapping would map ``u1000`` down to ``k21000``. The third idmapping would map
``u1000`` down to ``k31000``.

If we were given the same task for the following three idmappings::

 1. u0:k10000:r10000
 2. u0:k20000:r200
 3. u0:k30000:r300

we would fail to translate as the sets aren't order isomorphic over the full
range of the first idmapping anymore (However they are order isomorphic over
the full range of the second idmapping.). Neither the second or third idmapping
contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having
an id mapped. We can simply say that ``u1000`` is unmapped in the second and
third idmapping. The kernel will report unmapped ids as the overflowuid
``(uid_t)-1`` or overflowgid ``(gid_t)-1`` to userspace.

내리기와 올리기 계산식

주어진 ID의 대응값을 계산하는 알고리즘은 단순합니다. 먼저 대상 ID가 매핑 범위 안에 있는지 확인해야 하지만, 원문은 설명을 단순화하기 위해 이 검사를 생략합니다.

왼쪽에서 오른쪽으로, 즉 위쪽 집합에서 아래쪽 집합으로 내릴 때는 `id - u + k = n`을 사용합니다. 오른쪽에서 왼쪽으로, 즉 아래쪽 집합에서 위쪽 집합으로 올릴 때는 `id - k + u = n`을 사용합니다. 내리기와 올리기는 서로의 역연산입니다.

첫 매핑 `u0:k20000:r10000`에서 `k21000`을 올리면 `k21000 - k20000 + u0 = u1000`입니다. 둘째 매핑 `u500:k30000:r10000`에서 `u1100`을 내리면 `u1100 - u500 + k30000 = k30600`입니다.

The algorithm to calculate what a given id maps to is pretty simple. First, we
need to verify that the range can contain our target id. We will skip this step
for simplicity. After that if we want to know what ``id`` maps to we can do
simple calculations:

- If we want to map from left to right::

   u:k:r
   id - u + k = n

- If we want to map from right to left::

   u:k:r
   id - k + u = n

Instead of "left to right" we can also say "down" and instead of "right to
left" we can also say "up". Obviously mapping down and up invert each other.

To see whether the simple formulas above work, consider the following two
idmappings::

 1. u0:k20000:r10000
 2. u500:k30000:r10000

Assume we are given ``k21000`` in the lower idmapset of the first idmapping. We
want to know what id this was mapped from in the upper idmapset of the first
idmapping. So we're mapping up in the first idmapping::

 id     - k      + u  = n
 k21000 - k20000 + u0 = u1000

Now assume we are given the id ``u1100`` in the upper idmapset of the second
idmapping and we want to know what this id maps down to in the lower idmapset
of the second idmapping. This means we're mapping down in the second
idmapping::

 id    - u    + k      = n
 u1100 - u500 + k30000 = k30600

커널에서의 사용자 공간 ID와 커널 ID

커널 문맥에서 ID 매핑은 사용자 공간 ID 범위를 커널 ID 범위로 매핑하는 `userspace-id:kernel-id:range`로 해석할 수 있습니다. 사용자 공간 ID는 위쪽 집합의 `uid_t` 또는 `gid_t`이고, 커널 ID는 아래쪽 집합의 `kuid_t` 또는 `kgid_t`입니다. 이후 `사용자 공간 ID`는 `uid_t`와 `gid_t`, `커널 ID`는 `kuid_t`와 `kgid_t`를 뜻합니다.

커널은 주로 커널 ID를 사용합니다. 권한 검사에 쓰고 inode의 `i_uid`, `i_gid` 필드에 저장합니다. 반면 사용자 공간 ID는 커널이 사용자 공간에 보고하거나 사용자 공간이 커널에 전달하는 ID이며, 디스크에 기록되거나 디스크에서 읽히는 원시 장치 ID이기도 합니다. 여기서는 사용자 공간이 매핑을 지정하는 문법이 아니라 커널이 저장한 형태만 다룹니다.

이 문서에서 사용자 공간 ID에는 `u`, 커널 ID에는 `k`, 범위에는 `r`을 붙입니다. `u0:k10000:r10000`에서 `u1000`은 `u0`부터 시작하는 사용자 공간 집합의 원소이고, `k10000`부터 시작하는 커널 집합의 `k11000`으로 매핑됩니다.

커널 ID는 항상 user namespace에 연결된 ID 매핑으로 만들어집니다. 매핑 생성법과 파일시스템 밖의 사용법은 user namespace 설명의 영역이므로 여기서는 다루지 않습니다.

initial user namespace는 특별하며 항상 `u0:k0:r4294967295`라는 전체 ID 범위의 identity mapping을 갖습니다. 다른 user namespace는 보통 `u0:k10000:r10000` 같은 non-identity mapping을 사용합니다.

프로세스가 파일을 만들거나 소유권을 바꾸려 할 때, 또는 파일시스템이 디스크에서 소유권을 읽을 때 사용자 공간 ID는 관련 user namespace의 ID 매핑에 따라 즉시 커널 ID로 변환됩니다. 디스크의 소유자가 `u1000`인 파일을 initial 매핑으로 읽으면 inode의 `i_uid`와 `i_gid`는 `k1000`입니다. `u0:k10000:r10000` 매핑으로 mount했다면 두 필드는 `k11000`입니다.

General notes
-------------

In the context of the kernel an idmapping can be interpreted as mapping a range
of userspace ids into a range of kernel ids::

 userspace-id:kernel-id:range

A userspace id is always an element in the upper idmapset of an idmapping of
type ``uid_t`` or ``gid_t`` and a kernel id is always an element in the lower
idmapset of an idmapping of type ``kuid_t`` or ``kgid_t``. From now on
"userspace id" will be used to refer to the well known ``uid_t`` and ``gid_t``
types and "kernel id" will be used to refer to ``kuid_t`` and ``kgid_t``.

The kernel is mostly concerned with kernel ids. They are used when performing
permission checks and are stored in an inode's ``i_uid`` and ``i_gid`` field.
A userspace id on the other hand is an id that is reported to userspace by the
kernel, or is passed by userspace to the kernel, or a raw device id that is
written or read from disk.

Note that we are only concerned with idmappings as the kernel stores them not
how userspace would specify them.

For the rest of this document we will prefix all userspace ids with ``u`` and
all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So
an idmapping will be written as ``u0:k10000:r10000``.

For example, within this idmapping, the id ``u1000`` is an id in the upper
idmapset or "userspace idmapset" starting with ``u0``. And it is mapped to
``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset"
starting with ``k10000``.

A kernel id is always created by an idmapping. Such idmappings are associated
with user namespaces. Since we mainly care about how idmappings work we're not
going to be concerned with how idmappings are created nor how they are used
outside of the filesystem context. This is best left to an explanation of user
namespaces.

The initial user namespace is special. It always has an idmapping of the
following form::

 u0:k0:r4294967295

which is an identity idmapping over the full range of ids available on this
system.

Other user namespaces usually have non-identity idmappings such as::

 u0:k10000:r10000

When a process creates or wants to change ownership of a file, or when the
ownership of a file is read from disk by a filesystem, the userspace id is
immediately translated into a kernel id according to the idmapping associated
with the relevant user namespace.

For instance, consider a file that is stored on disk by a filesystem as being
owned by ``u1000``:

- If a filesystem were to be mounted in the initial user namespaces (as most
  filesystems are) then the initial idmapping will be used. As we saw this is
  simply the identity idmapping. This would mean id ``u1000`` read from disk
  would be mapped to id ``k1000``. So an inode's ``i_uid`` and ``i_gid`` field
  would contain ``k1000``.

- If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000``
  then ``u1000`` read from disk would be mapped to ``k11000``. So an inode's
  ``i_uid`` and ``i_gid`` would contain ``k11000``.

교차 매핑

교차 매핑(crossmapping)은 서로 다른 ID 매핑 사이의 변환 방식이며, 커널은 `stat()` 계열 system call로 파일 소유권을 사용자 공간에 보고할 때를 포함해 여러 곳에서 사용합니다.

한 매핑에서 얻은 `k11000`을 다른 매핑에서 올리려면 두 매핑의 커널 ID 집합이 같은 커널 ID를 포함해야 합니다. `u0:k10000:r10000`에서 `u1000`을 내린 `k11000`은, 커널 집합 시작점이 같은 `u20000:k10000:r10000`에서 `from_kuid(..., k11000) = u21000`으로 올라갑니다.

이 과정은 역으로 되돌릴 수 있습니다. 둘째 매핑에서 `make_kuid(..., u21000) = k11000`으로 내리고, 첫 매핑에서 `from_kuid(..., k11000) = u1000`으로 올리면 최초 ID를 얻습니다. 즉 교차 매핑은 특정 커널 ID가 주어진 매핑에서 어느 사용자 공간 ID에 해당하는지 답하며, 양쪽 커널 ID 집합에 같은 커널 ID가 있어야 합니다.

예를 들어 파일시스템 매핑이 `u0:k20000:r10000`이고 디스크에서 `u1000` 소유 파일을 읽으면 inode에는 `k21000`이 저장됩니다. `stat()` 호출자에게 보고할 때 파일시스템 매핑으로 바로 되올리면 호출자가 별도 매핑을 쓰는 경우 잘못된 소유자를 얻게 됩니다.

따라서 커널은 호출자의 매핑에서 이 ID를 올립니다. 호출자 매핑이 `u3000:k20000:r10000`이면 `k21000`은 `u4000`이 되어 사용자는 파일 소유자를 `u4000`으로 보게 됩니다.

Translation algorithms
----------------------

We've already seen briefly that it is possible to translate between different
idmappings. We'll now take a closer look how that works.

Crossmapping
~~~~~~~~~~~~

This translation algorithm is used by the kernel in quite a few places. For
example, it is used when reporting back the ownership of a file to userspace
via the ``stat()`` system call family.

If we've been given ``k11000`` from one idmapping we can map that id up in
another idmapping. In order for this to work both idmappings need to contain
the same kernel id in their kernel idmapsets. For example, consider the
following idmappings::

 1. u0:k10000:r10000
 2. u20000:k10000:r10000

and we are mapping ``u1000`` down to ``k11000`` in the first idmapping . We can
then translate ``k11000`` into a userspace id in the second idmapping using the
kernel idmapset of the second idmapping::

 /* Map the kernel id up into a userspace id in the second idmapping. */
 from_kuid(u20000:k10000:r10000, k11000) = u21000

Note, how we can get back to the kernel id in the first idmapping by inverting
the algorithm::

 /* Map the userspace id down into a kernel id in the second idmapping. */
 make_kuid(u20000:k10000:r10000, u21000) = k11000

 /* Map the kernel id up into a userspace id in the first idmapping. */
 from_kuid(u0:k10000:r10000, k11000) = u1000

This algorithm allows us to answer the question what userspace id a given
kernel id corresponds to in a given idmapping. In order to be able to answer
this question both idmappings need to contain the same kernel id in their
respective kernel idmapsets.

For example, when the kernel reads a raw userspace id from disk it maps it down
into a kernel id according to the idmapping associated with the filesystem.
Let's assume the filesystem was mounted with an idmapping of
``u0:k20000:r10000`` and it reads a file owned by ``u1000`` from disk. This
means ``u1000`` will be mapped to ``k21000`` which is what will be stored in
the inode's ``i_uid`` and ``i_gid`` field.

When someone in userspace calls ``stat()`` or a related function to get
ownership information about the file the kernel can't simply map the id back up
according to the filesystem's idmapping as this would give the wrong owner if
the caller is using an idmapping.

So the kernel will map the id back up in the idmapping of the caller. Let's
assume the caller has the somewhat unconventional idmapping
``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``.
Consequently the user would see that this file is owned by ``u4000``.

재매핑

두 ID 매핑의 사용자 공간 ID 집합을 경유하면 한 매핑의 커널 ID를 다른 매핑의 커널 ID로 변환할 수 있습니다. 이것이 커널 ID 재매핑(remapping)입니다.

`u0:k10000:r10000`의 `k11000`을 `u0:k20000:r10000`로 옮기려면 먼저 첫 매핑에서 `from_kuid(..., k11000) = u1000`으로 올리고, 둘째 매핑에서 `make_kuid(..., u1000) = k21000`으로 내립니다. 두 매핑의 사용자 공간 ID 집합에 공통으로 `u1000`이 있으므로 가능한 변환입니다.

역방향도 같습니다. 둘째 매핑의 `k21000`을 `u1000`으로 올린 뒤 첫 매핑으로 내려 `k11000`을 복원합니다. 따라서 재매핑은 관련 사용자 공간 ID가 양쪽에 매핑되어 있을 때 한 매핑을 역으로 적용하고 다른 매핑을 적용하는 것으로 볼 수 있습니다. 이 성질은 idmapped mount에서 핵심적으로 사용됩니다.

Remapping
~~~~~~~~~

It is possible to translate a kernel id from one idmapping to another one via
the userspace idmapset of the two idmappings. This is equivalent to remapping
a kernel id.

Let's look at an example. We are given the following two idmappings::

 1. u0:k10000:r10000
 2. u0:k20000:r10000

and we are given ``k11000`` in the first idmapping. In order to translate this
kernel id in the first idmapping into a kernel id in the second idmapping we
need to perform two steps:

1. Map the kernel id up into a userspace id in the first idmapping::

    /* Map the kernel id up into a userspace id in the first idmapping. */
    from_kuid(u0:k10000:r10000, k11000) = u1000

2. Map the userspace id down into a kernel id in the second idmapping::

    /* Map the userspace id down into a kernel id in the second idmapping. */
    make_kuid(u0:k20000:r10000, u1000) = k21000

As you can see we used the userspace idmapset in both idmappings to translate
the kernel id in one idmapping to a kernel id in another idmapping.

This allows us to answer the question what kernel id we would need to use to
get the same userspace id in another idmapping. In order to be able to answer
this question both idmappings need to contain the same userspace id in their
respective userspace idmapsets.

Note, how we can easily get back to the kernel id in the first idmapping by
inverting the algorithm:

1. Map the kernel id up into a userspace id in the second idmapping::

    /* Map the kernel id up into a userspace id in the second idmapping. */
    from_kuid(u0:k20000:r10000, k21000) = u1000

2. Map the userspace id down into a kernel id in the first idmapping::

    /* Map the userspace id down into a kernel id in the first idmapping. */
    make_kuid(u0:k10000:r10000, u1000) = k11000

Another way to look at this translation is to treat it as inverting one
idmapping and applying another idmapping if both idmappings have the relevant
userspace id mapped. This will come in handy when working with idmapped mounts.

잘못된 변환과 타입 안전성

어떤 ID 매핑의 커널 ID 집합에 속한 ID를 같은 매핑 또는 다른 매핑의 사용자 공간 ID 집합에 속한 ID처럼 사용하는 것은 절대 유효하지 않습니다. 커널 ID 집합은 커널 ID 공간을, 사용자 공간 ID 집합은 사용자 공간 ID를 나타내기 때문입니다.

따라서 첫 매핑에서 `u1000`을 `k11000`으로 내린 다음, 그 `k11000`을 둘째 `make_kuid()`의 사용자 공간 인수로 넘기는 것은 커널 ID를 다시 아래로 매핑하려는 오류입니다. 마찬가지로 첫 매핑에서 `k11000`을 `u1000`으로 올린 다음, 그 `u1000`을 둘째 `from_kuid()`의 커널 ID 인수로 넘기는 것도 사용자 공간 ID를 다시 위로 매핑하려는 오류입니다.

사용자 공간 ID는 `uid_t`와 `gid_t`, 커널 ID는 `kuid_t`와 `kgid_t`로 타입이 다릅니다. 이 타입 구분 덕분에 두 공간을 혼동한 원문의 잘못된 예들은 컴파일 단계에서 오류가 됩니다.

Invalid translations
~~~~~~~~~~~~~~~~~~~~

It is never valid to use an id in the kernel idmapset of one idmapping as the
id in the userspace idmapset of another or the same idmapping. While the kernel
idmapset always indicates an idmapset in the kernel id space the userspace
idmapset indicates a userspace id. So the following translations are forbidden::

 /* Map the userspace id down into a kernel id in the first idmapping. */
 make_kuid(u0:k10000:r10000, u1000) = k11000

 /* INVALID: Map the kernel id down into a kernel id in the second idmapping. */
 make_kuid(u10000:k20000:r10000, k110000) = k21000
                                 ~~~~~~~

and equally wrong::

 /* Map the kernel id up into a userspace id in the first idmapping. */
 from_kuid(u0:k10000:r10000, k11000) = u1000

 /* INVALID: Map the userspace id up into a userspace id in the second idmapping. */
 from_kuid(u20000:k0:r10000, u1000) = k21000
                             ~~~~~

Since userspace ids have type ``uid_t`` and ``gid_t`` and kernel ids have type
``kuid_t`` and ``kgid_t`` the compiler will throw an error when they are
conflated. So the two examples above would cause a compilation failure.

파일시스템 객체 생성 시의 ID 매핑

파일시스템 개발자에게 익숙한 `make_kuid(idmapping, uid)`는 사용자 공간 ID를 커널 ID로 내리고, `from_kuid(idmapping, kuid)`는 커널 ID를 사용자 공간 ID로 올립니다.

여기서는 VFS가 path lookup을 끝내고 `vfs_mkdir()` 같은 호출로 파일시스템 자체에 진입하기 직전부터만 간략히 살펴봅니다. 객체를 만들 directory는 누구나 읽고 쓸 수 있다고 가정합니다.

파일시스템 객체를 만들 때 호출자는 자신의 filesystem ID를 사용합니다. 이는 일반 `uid_t`, `gid_t` 사용자 공간 ID지만 파일 소유권을 결정할 때만 쓰기 때문에 filesystem ID라고 부릅니다. 보통 호출자의 uid/gid와 같지만 다를 수 있으며, 설명에서는 항상 같다고 가정합니다.

호출자가 커널에 들어오면 두 단계가 일어납니다. 첫째, 호출자의 사용자 공간 ID를 호출자 매핑에서 커널 ID로 내립니다. 정확히는 커널이 current task credential에 저장된 커널 ID를 읽지만, 설명에서는 이때 변환한다고 가정합니다. 둘째, 그 커널 ID를 파일시스템 매핑에서 유효한 사용자 공간 ID로 올릴 수 있는지 검증합니다.

둘째 검사가 중요한 이유는 일반 파일시스템이 디스크에 기록할 때 커널 ID를 다시 사용자 공간 ID로 올려야 하기 때문입니다. 유효한 ID를 쓸 수 없으면 커널은 파일시스템 손상 가능성을 피하려고 생성 요청을 거부합니다. 이는 호출자 매핑으로 내린 뒤 파일시스템 매핑으로 올리는 교차 매핑의 변형입니다.

구현에서 모든 ID 매핑은 대응하는 user namespace에서 옵니다. 호출자 매핑은 보통 `current_user_ns()`, 파일시스템 매핑은 `sb->s_user_ns`, mount 매핑은 `mnt_idmap(vfsmnt)`에서 가져옵니다. 다음 예제들은 먼저 mount 매핑 없이 문제를 보이고, 뒤에서 mount 매핑을 넣어 같은 문제를 다시 풉니다.

Idmappings when creating filesystem objects
-------------------------------------------

The concepts of mapping an id down or mapping an id up are expressed in the two
kernel functions filesystem developers are rather familiar with and which we've
already used in this document::

 /* Map the userspace id down into a kernel id. */
 make_kuid(idmapping, uid)

 /* Map the kernel id up into a userspace id. */
 from_kuid(idmapping, kuid)

We will take an abbreviated look into how idmappings figure into creating
filesystem objects. For simplicity we will only look at what happens when the
VFS has already completed path lookup right before it calls into the filesystem
itself. So we're concerned with what happens when e.g. ``vfs_mkdir()`` is
called. We will also assume that the directory we're creating filesystem
objects in is readable and writable for everyone.

When creating a filesystem object the caller will look at the caller's
filesystem ids. These are just regular ``uid_t`` and ``gid_t`` userspace ids
but they are exclusively used when determining file ownership which is why they
are called "filesystem ids". They are usually identical to the uid and gid of
the caller but can differ. We will just assume they are always identical to not
get lost in too many details.

When the caller enters the kernel two things happen:

1. Map the caller's userspace ids down into kernel ids in the caller's
   idmapping.
   (To be precise, the kernel will simply look at the kernel ids stashed in the
   credentials of the current task but for our education we'll pretend this
   translation happens just in time.)
2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
   filesystem's idmapping.

The second step is important as regular filesystem will ultimately need to map
the kernel id back up into a userspace id when writing to disk.
So with the second step the kernel guarantees that a valid userspace id can be
written to disk. If it can't the kernel will refuse the creation request to not
even remotely risk filesystem corruption.

The astute reader will have realized that this is simply a variation of the
crossmapping algorithm we mentioned above in a previous section. First, the
kernel maps the caller's userspace id down into a kernel id according to the
caller's idmapping and then maps that kernel id up according to the
filesystem's idmapping.

From the implementation point it's worth mentioning how idmappings are represented.
All idmappings are taken from the corresponding user namespace.

    - caller's idmapping (usually taken from ``current_user_ns()``)
    - filesystem's idmapping (``sb->s_user_ns``)
    - mount's idmapping (``mnt_idmap(vfsmnt)``)

Let's see some examples with caller/filesystem idmapping but without mount
idmappings. This will exhibit some problems we can hit. After that we will
revisit/reconsider these examples, this time using mount idmappings, to see how
they can solve the problems we observed before.

예제 1: 양쪽이 identity mapping인 경우

호출자 ID는 `u1000`이고 호출자와 파일시스템 모두 `u0:k0:r4294967295` identity mapping을 사용합니다.

호출자 매핑에서 `make_kuid(..., u1000) = k1000`으로 내립니다. 이어 `fsuidgid_has_mapping()`이 최종적으로 `from_kuid(..., k1000) = u1000`을 호출하여 파일시스템 매핑에서도 올릴 수 있음을 확인합니다.

두 매핑이 같으므로 추가적인 변화는 없고, 최종적으로 디스크에 기록되는 사용자 공간 ID는 `u1000`입니다.

Example 1
~~~~~~~~~

::

 caller id:            u1000
 caller idmapping:     u0:k0:r4294967295
 filesystem idmapping: u0:k0:r4294967295

Both the caller and the filesystem use the identity idmapping:

1. Map the caller's userspace ids into kernel ids in the caller's idmapping::

    make_kuid(u0:k0:r4294967295, u1000) = k1000

2. Verify that the caller's kernel ids can be mapped to userspace ids in the
   filesystem's idmapping.

   For this second step the kernel will call the function
   ``fsuidgid_has_mapping()`` which ultimately boils down to calling
   ``from_kuid()``::

    from_kuid(u0:k0:r4294967295, k1000) = u1000

In this example both idmappings are the same so there's nothing exciting going
on. Ultimately the userspace id that lands on disk will be ``u1000``.

예제 2: 겹치지 않는 비초기 매핑

호출자 ID `u1000`, 호출자 매핑 `u0:k10000:r10000`, 파일시스템 매핑 `u0:k20000:r10000`을 사용합니다.

호출자 매핑에서 `u1000`을 내리면 `k11000`입니다. 그러나 파일시스템 매핑의 커널 범위는 `k20000`부터이므로 `from_kuid(..., k11000) = u-1`이 되어 올릴 수 없습니다.

호출자의 사용자 공간 ID를 커널 ID로 만드는 데는 성공했지만 파일시스템 매핑에서 유효한 사용자 공간 ID를 얻지 못했으므로 커널은 생성 요청을 거부합니다. 대부분의 파일시스템을 non-initial 매핑으로 mount할 수 없어 이 구체적 구성은 덜 흔하지만, 뒤의 예제에서 보듯 문제 자체는 일반적입니다.

Example 2
~~~~~~~~~

::

 caller id:            u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k20000:r10000

1. Map the caller's userspace ids down into kernel ids in the caller's
   idmapping::

    make_kuid(u0:k10000:r10000, u1000) = k11000

2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
   filesystem's idmapping::

    from_kuid(u0:k20000:r10000, k11000) = u-1

It's immediately clear that while the caller's userspace id could be
successfully mapped down into kernel ids in the caller's idmapping the kernel
ids could not be mapped up according to the filesystem's idmapping. So the
kernel will deny this creation request.

Note that while this example is less common, because most filesystem can't be
mounted with non-initial idmappings this is a general problem as we can see in
the next examples.

예제 3: 호출자만 비초기 매핑인 경우

호출자 ID는 `u1000`, 호출자 매핑은 `u0:k10000:r10000`, 파일시스템 매핑은 initial identity mapping `u0:k0:r4294967295`입니다. 호출자 매핑에서 `u1000`을 내리면 `k11000`, 파일시스템 매핑에서 이를 올리면 `u11000`이므로 변환 자체는 항상 성공합니다.

그 결과 파일시스템이 디스크에 기록하는 사용자 공간 ID 값은 호출자 매핑에서 생성된 커널 ID의 숫자와 같습니다. 첫째 문제는 전체 파일시스템을 호출자 또는 다른 매핑으로 mount하지 않는 한 호출자가 디스크에 다른 사용자 공간 ID를 기록하게 할 수 없다는 점입니다. 일부 파일시스템만 가능한 이 방법은 유연하지 않으며, container workload에는 중요한 제약입니다.

둘째 문제는 파일시스템의 커널 ID가 호출자 매핑에서 유효한 사용자 공간 ID로 올라가지 않기 때문에 호출자가 보통 더 엄격한 권한의 directory에 접근하거나 파일을 만들 수 없다는 점입니다. 디스크의 `u1000`은 파일시스템 매핑에서 `k1000`이지만 호출자 매핑에서 `from_kuid(..., k1000) = u-1`입니다.

Example 3
~~~~~~~~~

::

 caller id:            u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k0:r4294967295

1. Map the caller's userspace ids down into kernel ids in the caller's
   idmapping::

    make_kuid(u0:k10000:r10000, u1000) = k11000

2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
   filesystem's idmapping::

    from_kuid(u0:k0:r4294967295, k11000) = u11000

We can see that the translation always succeeds. The userspace id that the
filesystem will ultimately put to disk will always be identical to the value of
the kernel id that was created in the caller's idmapping. This has mainly two
consequences.

First, that we can't allow a caller to ultimately write to disk with another
userspace id. We could only do this if we were to mount the whole filesystem
with the caller's or another idmapping. But that solution is limited to a few
filesystems and not very flexible. But this is a use-case that is pretty
important in containerized workloads.

Second, the caller will usually not be able to create any files or access
directories that have stricter permissions because none of the filesystem's
kernel ids map up into valid userspace ids in the caller's idmapping

1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::

    make_kuid(u0:k0:r4294967295, u1000) = k1000

2. Map kernel ids up to userspace ids in the caller's idmapping::

    from_kuid(u0:k10000:r10000, k1000) = u-1

예제 4: initial 파일시스템의 소유권 보고 실패

디스크 파일 ID는 `u1000`, 호출자 매핑은 `u0:k10000:r10000`, 파일시스템 매핑은 initial identity mapping `u0:k0:r4294967295`입니다.

소유권을 보고하려고 디스크의 `u1000`을 파일시스템 매핑에서 내리면 `k1000`입니다. 이를 호출자 매핑에서 올리려 하면 `from_kuid(..., k1000) = u-1`입니다.

파일시스템 매핑의 커널 ID가 호출자 매핑의 사용자 공간 ID로 교차 매핑되지 않으므로 알고리즘은 실패하고, 커널은 이 파일의 소유권을 overflowid로 보고합니다.

Example 4
~~~~~~~~~

::

 file id:              u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k0:r4294967295

In order to report ownership to userspace the kernel uses the crossmapping
algorithm introduced in a previous section:

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k0:r4294967295, u1000) = k1000

2. Map the kernel id up into a userspace id in the caller's idmapping::

    from_kuid(u0:k10000:r10000, k1000) = u-1

The crossmapping algorithm fails in this case because the kernel id in the
filesystem idmapping cannot be mapped up to a userspace id in the caller's
idmapping. Thus, the kernel will report the ownership of this file as the
overflowid.

예제 5: 두 비초기 매핑의 소유권 보고

디스크 파일 ID는 `u1000`, 호출자 매핑은 `u0:k10000:r10000`, 파일시스템 매핑은 `u0:k20000:r10000`입니다.

디스크의 `u1000`을 파일시스템 매핑으로 내리면 `k21000`입니다. 호출자 매핑에서 `k21000`을 올리려 하면 범위가 겹치지 않아 `u-1`이 됩니다. 따라서 이 경우도 커널은 소유권을 overflowid로 보고합니다.

마지막 두 예제에서 호출자가 initial mapping을 사용했다면 단순해집니다. 파일시스템 매핑 `u0:k20000:r10000`에서 디스크의 `u1000`은 `k21000`이고, 호출자의 identity mapping `u0:k0:r4294967295`에서 이를 올리면 `u21000`입니다.

Example 5
~~~~~~~~~

::

 file id:              u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k20000:r10000

In order to report ownership to userspace the kernel uses the crossmapping
algorithm introduced in a previous section:

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k20000:r10000, u1000) = k21000

2. Map the kernel id up into a userspace id in the caller's idmapping::

    from_kuid(u0:k10000:r10000, k21000) = u-1

Again, the crossmapping algorithm fails in this case because the kernel id in
the filesystem idmapping cannot be mapped to a userspace id in the caller's
idmapping. Thus, the kernel will report the ownership of this file as the
overflowid.

Note how in the last two examples things would be simple if the caller would be
using the initial idmapping. For a filesystem mounted with the initial
idmapping it would be trivial. So we only consider a filesystem with an
idmapping of ``u0:k20000:r10000``:

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k20000:r10000, u1000) = k21000

2. Map the kernel id up into a userspace id in the caller's idmapping::

    from_kuid(u0:k0:r4294967295, k21000) = u21000

idmapped mount의 필요성과 범위

호출자 매핑과 파일시스템 매핑이 호환되지 않으면 workload에 여러 문제가 생깁니다. 흔한 예로 host에서 서로 영향을 주지 못하도록 겹치지 않는 `u0:k10000:r10000`, `u0:k20000:r10000`을 사용하는 두 container와 `u0:k30000:r10000` 파일시스템을 생각할 수 있습니다.

관리자는 `u0`, `u1000`, `u2000` 소유인 `dir`, `dir/file1`, `dir/file2`를 두 container에 모두 쉽게 read-write로 제공할 수 없습니다. `chown()`으로 재귀적으로 소유권을 `u10000`, `u11000`, `u12000`으로 바꾸면 첫 container와는 교차 매핑되지만 둘째 container에서는 계속 overflowid 소유로 보입니다.

또 다른 예는 systemd 같은 service manager의 portable home directory입니다. 집에서는 로그인 ID `u1000`이고 모든 home 파일도 `u1000` 소유지만 학교나 직장에서는 `u1125`일 수 있어 같은 home directory를 사용하기 어렵습니다.

두 경우 모두 재귀적 소유권 변경은 전역적이고 영구적이라는 심각한 문제가 있습니다. portable home은 장소를 옮길 때마다 바꿔야 하며 파일이 많을수록 비용도 커집니다.

파일시스템을 user namespace 안에서 mount할 수 있다 해도 소유권은 전역적으로 바뀌고 superblock 수명에 묶입니다. 소유권을 다시 바꾸려면 완전히 unmount한 뒤 다른 user namespace에서 mount해야 하므로 현재 사용자들의 접근을 끊어야 하며, 서로 다른 매핑의 두 container가 같은 `dir`을 공유하는 문제도 해결하지 못합니다. 대부분의 파일시스템은 container 안에서 mount할 수도 없고, 악의적인 filesystem image를 다룰 필요가 없다는 점에서는 이것이 바람직할 수도 있습니다.

idmapped mount는 같은 dentry 집합을 mount마다 다른 소유권으로 노출합니다. `mount_setattr()` system call로 mount에 user namespace를 표시하고, 연결된 ID 매핑을 앞서 설명한 재매핑 알고리즘에 사용하여 호출자 매핑과 파일시스템 매핑 사이를 양방향으로 변환합니다.

이 방식의 소유권 변경은 임시적이고 지역적입니다. 특정 mount와 그 수명에만 한정되므로 다른 사용자와 파일시스템의 다른 노출 위치는 영향을 받지 않습니다.

idmapped mount를 지원하는 파일시스템은 같은 효과를 얻기 위해 user namespace 안에서 직접 mount되는 기능을 굳이 지원할 필요가 없습니다. initial user namespace의 권한 있는 사용자가 superblock을 만들고 전체 파일시스템을 idmapped mount 아래에 노출할 수 있습니다. 두 기능을 함께 사용하는 것도 가능하며 뒤에서 다시 다룹니다.

Idmappings on idmapped mounts
-----------------------------

The examples we've seen in the previous section where the caller's idmapping
and the filesystem's idmapping are incompatible causes various issues for
workloads. For a more complex but common example, consider two containers
started on the host. To completely prevent the two containers from affecting
each other, an administrator may often use different non-overlapping idmappings
for the two containers::

 container1 idmapping:  u0:k10000:r10000
 container2 idmapping:  u0:k20000:r10000
 filesystem idmapping:  u0:k30000:r10000

An administrator wanting to provide easy read-write access to the following set
of files::

 dir id:       u0
 dir/file1 id: u1000
 dir/file2 id: u2000

to both containers currently can't.

Of course the administrator has the option to recursively change ownership via
``chown()``. For example, they could change ownership so that ``dir`` and all
files below it can be crossmapped from the filesystem's into the container's
idmapping. Let's assume they change ownership so it is compatible with the
first container's idmapping::

 dir id:       u10000
 dir/file1 id: u11000
 dir/file2 id: u12000

This would still leave ``dir`` rather useless to the second container. In fact,
``dir`` and all files below it would continue to appear owned by the overflowid
for the second container.

Or consider another increasingly popular example. Some service managers such as
systemd implement a concept called "portable home directories". A user may want
to use their home directories on different machines where they are assigned
different login userspace ids. Most users will have ``u1000`` as the login id
on their machine at home and all files in their home directory will usually be
owned by ``u1000``. At uni or at work they may have another login id such as
``u1125``. This makes it rather difficult to interact with their home directory
on their work machine.

In both cases changing ownership recursively has grave implications. The most
obvious one is that ownership is changed globally and permanently. In the home
directory case this change in ownership would even need to happen every time the
user switches from their home to their work machine. For really large sets of
files this becomes increasingly costly.

If the user is lucky, they are dealing with a filesystem that is mountable
inside user namespaces. But this would also change ownership globally and the
change in ownership is tied to the lifetime of the filesystem mount, i.e. the
superblock. The only way to change ownership is to completely unmount the
filesystem and mount it again in another user namespace. This is usually
impossible because it would mean that all users currently accessing the
filesystem can't anymore. And it means that ``dir`` still can't be shared
between two containers with different idmappings.
But usually the user doesn't even have this option since most filesystems
aren't mountable inside containers. And not having them mountable might be
desirable as it doesn't require the filesystem to deal with malicious
filesystem images.

But the usecases mentioned above and more can be handled by idmapped mounts.
They allow to expose the same set of dentries with different ownership at
different mounts. This is achieved by marking the mounts with a user namespace
through the ``mount_setattr()`` system call. The idmapping associated with it
is then used to translate from the caller's idmapping to the filesystem's
idmapping and vica versa using the remapping algorithm we introduced above.

Idmapped mounts make it possible to change ownership in a temporary and
localized way. The ownership changes are restricted to a specific mount and the
ownership changes are tied to the lifetime of the mount. All other users and
locations where the filesystem is exposed are unaffected.

Filesystems that support idmapped mounts don't have any real reason to support
being mountable inside user namespaces. A filesystem could be exposed
completely under an idmapped mount to get the same effect. This has the
advantage that filesystems can leave the creation of the superblock to
privileged users in the initial user namespace.

However, it is perfectly possible to combine idmapped mounts with filesystems
mountable inside user namespaces. We will touch on this further below.

파일시스템 ID 타입과 mount ID 타입

idmapped mount가 도입되면서 inode 같은 VFS 객체의 파일시스템 관점 소유권과 mount 관점 소유권을 구분해야 합니다. 같은 inode도 파일시스템에서 본 소유자와 idmapped mount에서 본 소유자가 다를 수 있으므로 이 근본적 차이를 코드에 드러내는 별도 타입이 도입되었습니다.

파일시스템 또는 호출자 ID 매핑으로 생성한 uid/gid에는 `kuid_t`, `kgid_t`를 사용합니다. mount ID 매핑으로 생성한 uid/gid에는 전용 `vfsuid_t`, `vfsgid_t`를 사용합니다. uid/gid를 만들거나 인수로 받는 모든 VFS helper는 VFS 타입을 사용하므로 컴파일러가 파일시스템 ID와 VFS ID를 혼동한 오류를 잡을 수 있습니다.

변환 관계는 `uid_t <--> kuid_t <--> vfsuid_t`, `gid_t <--> kgid_t <--> vfsgid_t`입니다. `stat()`처럼 VFS ID 기반 소유권을 보고하거나 `chown()`처럼 VFS ID 기반 값을 공유 VFS 객체에 저장할 때 `vfsuid_into_kuid()`와 `vfsgid_into_kgid()`를 사용할 수 있습니다.

idmapped mount에서 inode 소유권을 바꾸면 먼저 mount 매핑 기반의 `vfsuid_t` 또는 `vfsgid_t`가 생기고, 이를 파일시스템 전체에 적용되는 새 소유권으로 확정해야 합니다. 이때 helper가 VFS ID를 전역 `kuid_t` 또는 `kgid_t`로 바꿉니다.

cached `struct inode`나 cached `struct posix_acl` 같은 공유 VFS 객체에 소유권을 저장할 때는 반드시 파일시스템 또는 전역 `kuid_t`, `kgid_t`를 써야 합니다. `vfsuid_t`, `vfsgid_t` 소유권은 특정 idmapped mount에만 유효합니다.

파일시스템 매핑으로 VFS 타입을 만들거나 mount 매핑으로 커널 타입을 만드는 오용을 막기 위해 매핑 자체의 타입도 분리되어 있습니다. VFS 타입을 변환하는 모든 helper는 `struct mnt_idmap` 타입의 mount 매핑을 요구하며 파일시스템 또는 호출자 매핑을 넘기면 컴파일 오류가 납니다.

이후 VFS ID에는 `v` 접두사를 붙이며 mount ID 매핑은 `u0:v10000:r10000`처럼 씁니다.

Filesystem types vs idmapped mount types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

With the introduction of idmapped mounts we need to distinguish between
filesystem ownership and mount ownership of a VFS object such as an inode. The
owner of a inode might be different when looked at from a filesystem
perspective than when looked at from an idmapped mount. Such fundamental
conceptual distinctions should almost always be clearly expressed in the code.
So, to distinguish idmapped mount ownership from filesystem ownership separate
types have been introduced.

If a uid or gid has been generated using the filesystem or caller's idmapping
then we will use the ``kuid_t`` and ``kgid_t`` types. However, if a uid or gid
has been generated using a mount idmapping then we will be using the dedicated
``vfsuid_t`` and ``vfsgid_t`` types.

All VFS helpers that generate or take uids and gids as arguments use the
``vfsuid_t`` and ``vfsgid_t`` types and we will be able to rely on the compiler
to catch errors that originate from conflating filesystem and VFS uids and gids.

The ``vfsuid_t`` and ``vfsgid_t`` types are often mapped from and to ``kuid_t``
and ``kgid_t`` types similar how ``kuid_t`` and ``kgid_t`` types are mapped
from and to ``uid_t`` and ``gid_t`` types::

 uid_t <--> kuid_t <--> vfsuid_t
 gid_t <--> kgid_t <--> vfsgid_t

Whenever we report ownership based on a ``vfsuid_t`` or ``vfsgid_t`` type,
e.g., during ``stat()``, or store ownership information in a shared VFS object
based on a ``vfsuid_t`` or ``vfsgid_t`` type, e.g., during ``chown()`` we can
use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers.

To illustrate why this helper currently exists, consider what happens when we
change ownership of an inode from an idmapped mount. After we generated
a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to
this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership.
Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t``
or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and
``vfsgid_into_kgid()``.

Note, whenever a shared VFS object, e.g., a cached ``struct inode`` or a cached
``struct posix_acl``, stores ownership information a filesystem or "global"
``kuid_t`` and ``kgid_t`` must be used. Ownership expressed via ``vfsuid_t``
and ``vfsgid_t`` is specific to an idmapped mount.

We already noted that ``vfsuid_t`` and ``vfsgid_t`` types are generated based
on mount idmappings whereas ``kuid_t`` and ``kgid_t`` types are generated based
on filesystem idmappings. To prevent abusing filesystem idmappings to generate
``vfsuid_t`` or ``vfsgid_t`` types or mount idmappings to generate ``kuid_t``
or ``kgid_t`` types filesystem idmappings and mount idmappings are different
types as well.

All helpers that map to or from ``vfsuid_t`` and ``vfsgid_t`` types require
a mount idmapping to be passed which is of type ``struct mnt_idmap``. Passing
a filesystem or caller idmapping will cause a compilation error.

Similar to how we prefix all userspace ids in this document with ``u`` and all
kernel ids with ``k`` we will prefix all VFS ids with ``v``. So a mount
idmapping will be written as: ``u0:v10000:r10000``.

재매핑 helper와 왕복 보존

ID 매핑 사이를 변환하는 helper들은 앞서 설명한 재매핑 알고리즘을 사용합니다. `i_uid_into_vfsuid()`와 `i_gid_into_vfsgid()`는 파일시스템 커널 ID를 파일시스템 매핑에서 사용자 공간 ID로 올린 다음, mount 매핑에서 VFS ID로 내립니다.

`mapped_fsuid()`와 `mapped_fsgid()`는 mount 매핑을 이용해 호출자의 VFS ID를 재매핑하여 파일시스템 매핑의 커널 ID로 바꿉니다. 먼저 mount 매핑에서 사용자 공간 ID로 올리고, 그 ID를 파일시스템 매핑에서 커널 ID로 내립니다.

원문은 `vfsuid_into_kuid()`와 `vfsgid_into_kgid()` 항목을 `Whenever`라는 미완성 문장 조각으로 남겨 둡니다. 이 결락을 임의로 보충하지 않고 그대로 보존합니다. 이어지는 설명에서는 앞의 읽기 변환과 쓰기 변환이 서로를 뒤집는다고 설명합니다.

호출자 매핑 `u0:k10000:r10000`, 파일시스템 매핑 `u0:k20000:r10000`, mount 매핑 `u0:v10000:r10000`을 사용한다고 합시다. 디스크의 `u1000`은 파일시스템 매핑으로 `k21000`이 되어 inode의 `i_uid`, `i_gid`에 저장됩니다.

idmapped mount에서 `stat()`을 수행하면 `i_uid_into_vfsuid(k21000)`가 파일시스템 매핑에서 `k21000 -> u1000`으로 올리고 mount 매핑에서 `u1000 -> v11000`으로 내립니다. 이후 `vfsuid_into_kuid(v11000) = k11000`과 호출자 매핑의 `from_kuid(..., k11000) = u1000`을 거쳐 호출자에게 원래 소유권을 보고합니다.

새 파일 생성에서는 호출자의 `u1000`이 호출자 매핑에서 `k11000`이 됩니다. 일반 교차 매핑만으로는 이 ID를 파일시스템 매핑에서 올릴 수 없어 요청이 실패합니다. idmapped mount에서는 `mapped_fsuid()`가 mount 매핑을 경유하여 호출자 ID를 파일시스템 ID로 재매핑합니다.

원문의 이 생성 예제는 앞서 선언한 mount 매핑 `u0:v10000:r10000`과 달리 계산 안에서 `u0:v20000:r10000`을 사용해 `v21000`을 만듭니다. 원문 표기를 수정하지 않고 보존하면, 이어 `vfsuid_into_kuid(v21000) = k21000`, 파일시스템 매핑의 `from_kuid(..., k21000) = u1000`으로 디스크에 쓸 ID를 얻습니다.

결과 알고리즘은 역변환 가능하여 정보를 보존합니다. idmapped mount에서 `u1000`으로 만든 파일은 다시 `u1000` 소유로 보고되고 그 반대 방향도 성립합니다. 다음 절은 앞에서 실패한 예들을 mount 매핑과 함께 다시 검토합니다.

Remapping helpers
~~~~~~~~~~~~~~~~~

Idmapping functions were added that translate between idmappings. They make use
of the remapping algorithm we've introduced earlier. We're going to look at:

- ``i_uid_into_vfsuid()`` and ``i_gid_into_vfsgid()``

  The ``i_*id_into_vfs*id()`` functions translate filesystem's kernel ids into
  VFS ids in the mount's idmapping::

   /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
   from_kuid(filesystem, kid) = uid

   /* Map the filesystem's userspace id down ito a VFS id in the mount's idmapping. */
   make_kuid(mount, uid) = kuid

- ``mapped_fsuid()`` and ``mapped_fsgid()``

  The ``mapped_fs*id()`` functions translate the caller's kernel ids into
  kernel ids in the filesystem's idmapping. This translation is achieved by
  remapping the caller's VFS ids using the mount's idmapping::

   /* Map the caller's VFS id up into a userspace id in the mount's idmapping. */
   from_kuid(mount, kid) = uid

   /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
   make_kuid(filesystem, uid) = kuid

- ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()``

   Whenever

Note that these two functions invert each other. Consider the following
idmappings::

 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k20000:r10000
 mount idmapping:      u0:v10000:r10000

Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id
to ``k21000`` according to its idmapping. This is what is stored in the
inode's ``i_uid`` and ``i_gid`` fields.

When the caller queries the ownership of this file via ``stat()`` the kernel
would usually simply use the crossmapping algorithm and map the filesystem's
kernel id up to a userspace id in the caller's idmapping.

But when the caller is accessing the file on an idmapped mount the kernel will
first call ``i_uid_into_vfsuid()`` thereby translating the filesystem's kernel
id into a VFS id in the mount's idmapping::

 i_uid_into_vfsuid(k21000):
   /* Map the filesystem's kernel id up into a userspace id. */
   from_kuid(u0:k20000:r10000, k21000) = u1000

   /* Map the filesystem's userspace id down into a VFS id in the mount's idmapping. */
   make_kuid(u0:v10000:r10000, u1000) = v11000

Finally, when the kernel reports the owner to the caller it will turn the
VFS id in the mount's idmapping into a userspace id in the caller's
idmapping::

  k11000 = vfsuid_into_kuid(v11000)
  from_kuid(u0:k10000:r10000, k11000) = u1000

We can test whether this algorithm really works by verifying what happens when
we create a new file. Let's say the user is creating a file with ``u1000``.

The kernel maps this to ``k11000`` in the caller's idmapping. Usually the
kernel would now apply the crossmapping, verifying that ``k11000`` can be
mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't
be mapped up in the filesystem's idmapping directly this creation request
fails.

But when the caller is accessing the file on an idmapped mount the kernel will
first call ``mapped_fs*id()`` thereby translating the caller's kernel id into
a VFS id according to the mount's idmapping::

 mapped_fsuid(k11000):
    /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
    from_kuid(u0:k10000:r10000, k11000) = u1000

    /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
    make_kuid(u0:v20000:r10000, u1000) = v21000

When finally writing to disk the kernel will then map ``v21000`` up into a
userspace id in the filesystem's idmapping::

   k21000 = vfsuid_into_kuid(v21000)
   from_kuid(u0:k20000:r10000, k21000) = u1000

As we can see, we end up with an invertible and therefore information
preserving algorithm. A file created from ``u1000`` on an idmapped mount will
also be reported as being owned by ``u1000`` and vica versa.

Let's now briefly reconsider the failing examples from earlier in the context
of idmapped mounts.

예제 2 재검토: mount 매핑으로 생성 성공

호출자 ID `u1000`, 호출자 매핑 `u0:k10000:r10000`, 파일시스템 매핑 `u0:k20000:r10000`, mount 매핑 `u0:v10000:r10000`입니다. non-initial 매핑을 쓰는 호출자에게 같은 매핑을 mount에도 붙이는 것이 일반적입니다.

먼저 호출자 매핑에서 `u1000 -> k11000`으로 내립니다. 이어 `mapped_fsuid(v11000)`가 mount 매핑에서 `v11000 -> u1000`으로 올리고 파일시스템 매핑에서 `u1000 -> k21000`으로 내립니다.

마지막으로 파일시스템 매핑에서 `k21000 -> u1000`으로 올릴 수 있음을 검증합니다. mount 매핑이 없을 때 `u-1`이었던 예제와 달리 생성에 성공하며 디스크에 기록되는 소유권은 `u1000`입니다.

Example 2 reconsidered
~~~~~~~~~~~~~~~~~~~~~~

::

 caller id:            u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k20000:r10000
 mount idmapping:      u0:v10000:r10000

When the caller is using a non-initial idmapping the common case is to attach
the same idmapping to the mount. We now perform three steps:

1. Map the caller's userspace ids into kernel ids in the caller's idmapping::

    make_kuid(u0:k10000:r10000, u1000) = k11000

2. Translate the caller's VFS id into a kernel id in the filesystem's
   idmapping::

    mapped_fsuid(v11000):
      /* Map the VFS id up into a userspace id in the mount's idmapping. */
      from_kuid(u0:v10000:r10000, v11000) = u1000

      /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
      make_kuid(u0:k20000:r10000, u1000) = k21000

3. Verify that the caller's kernel ids can be mapped to userspace ids in the
   filesystem's idmapping::

    from_kuid(u0:k20000:r10000, k21000) = u1000

So the ownership that lands on disk will be ``u1000``.

예제 3 재검토: initial 파일시스템으로 재매핑

호출자 ID `u1000`, 호출자 매핑 `u0:k10000:r10000`, 파일시스템 identity mapping `u0:k0:r4294967295`, mount 매핑 `u0:v10000:r10000`입니다.

호출자 매핑에서 `u1000 -> k11000`으로 내립니다. `mapped_fsuid(v11000)`는 mount 매핑에서 `v11000 -> u1000`으로 올린 뒤 파일시스템의 identity mapping에서 `u1000 -> k1000`으로 내립니다.

파일시스템 매핑에서 `k1000 -> u1000`으로 다시 올릴 수 있으므로 검증에 성공하고, 디스크에 기록되는 소유권은 `u1000`입니다.

Example 3 reconsidered
~~~~~~~~~~~~~~~~~~~~~~

::

 caller id:            u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k0:r4294967295
 mount idmapping:      u0:v10000:r10000

The same translation algorithm works with the third example.

1. Map the caller's userspace ids into kernel ids in the caller's idmapping::

    make_kuid(u0:k10000:r10000, u1000) = k11000

2. Translate the caller's VFS id into a kernel id in the filesystem's
   idmapping::

    mapped_fsuid(v11000):
       /* Map the VFS id up into a userspace id in the mount's idmapping. */
       from_kuid(u0:v10000:r10000, v11000) = u1000

       /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
       make_kuid(u0:k0:r4294967295, u1000) = k1000

3. Verify that the caller's kernel ids can be mapped to userspace ids in the
   filesystem's idmapping::

    from_kuid(u0:k0:r4294967295, k1000) = u1000

So the ownership that lands on disk will be ``u1000``.

예제 4 재검토: 소유권 보고 복구

디스크 파일 ID `u1000`, 호출자 매핑 `u0:k10000:r10000`, 파일시스템 identity mapping, mount 매핑 `u0:v10000:r10000`입니다.

먼저 디스크의 `u1000`을 파일시스템 매핑에서 `k1000`으로 내립니다. `i_uid_into_vfsuid(k1000)`는 이를 파일시스템 매핑에서 `u1000`으로 올리고 mount 매핑에서 `v11000`으로 내립니다.

마지막으로 `vfsuid_into_kuid(v11000) = k11000`을 거쳐 호출자 매핑에서 `k11000 -> u1000`으로 올립니다. 앞에서는 호출자 커널 ID를 파일시스템 매핑으로 교차 매핑할 수 없었지만, 이제 mount 매핑을 경유해 가능해졌고 mount 관점의 파일 소유자는 `u1000`입니다.

Example 4 reconsidered
~~~~~~~~~~~~~~~~~~~~~~

::

 file id:              u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k0:r4294967295
 mount idmapping:      u0:v10000:r10000

In order to report ownership to userspace the kernel now does three steps using
the translation algorithm we introduced earlier:

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k0:r4294967295, u1000) = k1000

2. Translate the kernel id into a VFS id in the mount's idmapping::

    i_uid_into_vfsuid(k1000):
      /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
      from_kuid(u0:k0:r4294967295, k1000) = u1000

      /* Map the userspace id down into a VFS id in the mounts's idmapping. */
      make_kuid(u0:v10000:r10000, u1000) = v11000

3. Map the VFS id up into a userspace id in the caller's idmapping::

    k11000 = vfsuid_into_kuid(v11000)
    from_kuid(u0:k10000:r10000, k11000) = u1000

Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
idmapping. With the idmapped mount in place it now can be crossmapped into the
filesystem's idmapping via the mount's idmapping. The file will now be created
with ``u1000`` according to the mount's idmapping.

예제 5 재검토: 두 비초기 매핑 연결

디스크 파일 ID `u1000`, 호출자 매핑 `u0:k10000:r10000`, 파일시스템 매핑 `u0:k20000:r10000`, mount 매핑 `u0:v10000:r10000`입니다.

디스크의 `u1000`을 파일시스템 매핑으로 내리면 `k21000`입니다. `i_uid_into_vfsuid(k21000)`는 파일시스템 매핑에서 `u1000`으로 올리고 mount 매핑에서 `v11000`으로 내립니다.

`vfsuid_into_kuid(v11000) = k11000`을 거쳐 호출자 매핑에서 `k11000 -> u1000`으로 올립니다. 이전에는 파일의 커널 ID를 호출자 매핑으로 교차 매핑할 수 없었지만, mount 매핑이 중간 좌표를 제공하므로 파일은 mount 관점에서 `u1000` 소유로 보입니다.

Example 5 reconsidered
~~~~~~~~~~~~~~~~~~~~~~

::

 file id:              u1000
 caller idmapping:     u0:k10000:r10000
 filesystem idmapping: u0:k20000:r10000
 mount idmapping:      u0:v10000:r10000

Again, in order to report ownership to userspace the kernel now does three
steps using the translation algorithm we introduced earlier:

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k20000:r10000, u1000) = k21000

2. Translate the kernel id into a VFS id in the mount's idmapping::

    i_uid_into_vfsuid(k21000):
      /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
      from_kuid(u0:k20000:r10000, k21000) = u1000

      /* Map the userspace id down into a VFS id in the mounts's idmapping. */
      make_kuid(u0:v10000:r10000, u1000) = v11000

3. Map the VFS id up into a userspace id in the caller's idmapping::

    k11000 = vfsuid_into_kuid(v11000)
    from_kuid(u0:k10000:r10000, k11000) = u1000

Earlier, the file's kernel id couldn't be crossmapped in the filesystems's
idmapping. With the idmapped mount in place it now can be crossmapped into the
filesystem's idmapping via the mount's idmapping. The file is now owned by
``u1000`` according to the mount's idmapping.

portable home directory의 소유권 변환

호출자나 파일시스템 또는 둘 다 non-initial 매핑을 쓰면 커널 ID를 서로 교차 매핑하지 못해 파일시스템 접근이 실패할 수 있습니다. 이런 상황은 container workload에서 흔하며, idmapped mount는 호출자 또는 파일시스템 매핑을 mount 매핑에 따라 재매핑해 해결합니다.

idmapped mount는 호출자와 파일시스템이 모두 initial mapping을 쓰는 host에서도 유용합니다. 사용자는 mount마다 directory와 파일의 소유권 관점을 바꿀 수 있습니다.

portable storage의 home directory가 디스크에서는 `u1000` 소유이고, 사용자의 집 로그인 ID는 `u1000`, 직장 로그인 ID는 `u1125`라고 합시다. 그대로 가져가면 느슨한 권한이나 ACL 없이 파일에 접근하거나 기록하기 어렵고, 가능하더라도 `u1000`과 `u1125` 소유 파일이 섞입니다.

사용자는 휴대 저장장치에 최종적으로 남길 소유권에 따라 집 또는 직장 컴퓨터에서 home directory용 idmapped mount를 만들 수 있습니다. 디스크의 모든 파일을 `u1000` 소유로 유지하려면 직장에서 최소 매핑 `u1000:k1125:r1`을 가진 mount를 준비합니다. 원문의 mount 표기는 VFS 접두사를 적용해 `u1000:v1125:r1`로 제시됩니다.

직장 호출자 ID `u1125`, 호출자와 파일시스템의 identity mapping, mount 매핑 `u1000:v1125:r1`에서 파일을 만들면 먼저 `u1125 -> k1125`로 내립니다. `mapped_fsuid(v1125)`는 mount 매핑에서 `v1125 -> u1000`으로 올리고 파일시스템 identity mapping에서 `u1000 -> k1000`으로 내립니다. 파일시스템 매핑에서 `k1000 -> u1000`이 가능하므로 디스크에는 최종적으로 `u1000` 소유 파일이 만들어집니다.

반대로 직장 호출자에게 보일 소유권을 계산하면, 디스크의 `u1000`은 파일시스템 identity mapping에서 `k1000`입니다. `i_uid_into_vfsuid(k1000)`가 이를 다시 `u1000`으로 올린 뒤 mount 매핑에서 `v1125`로 내립니다. `vfsuid_into_kuid(v1125) = k1125`, 호출자 identity mapping의 `k1125 -> u1125`를 거쳐 직장에서는 호출자의 로그인 ID `u1125` 소유로 보고됩니다.

디스크에 실제 기록된 원시 사용자 공간 ID는 계속 `u1000`입니다. 따라서 저장장치를 집으로 가져가 `u1000`을 할당받은 사용자가 initial ID 매핑으로 파일시스템을 mount하면 모든 파일을 `u1000` 소유로 봅니다.

Changing ownership on a home directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We've seen above how idmapped mounts can be used to translate between
idmappings when either the caller, the filesystem or both uses a non-initial
idmapping. A wide range of usecases exist when the caller is using
a non-initial idmapping. This mostly happens in the context of containerized
workloads. The consequence is as we have seen that for both, filesystem's
mounted with the initial idmapping and filesystems mounted with non-initial
idmappings, access to the filesystem isn't working because the kernel ids can't
be crossmapped between the caller's and the filesystem's idmapping.

As we've seen above idmapped mounts provide a solution to this by remapping the
caller's or filesystem's idmapping according to the mount's idmapping.

Aside from containerized workloads, idmapped mounts have the advantage that
they also work when both the caller and the filesystem use the initial
idmapping which means users on the host can change the ownership of directories
and files on a per-mount basis.

Consider our previous example where a user has their home directory on portable
storage. At home they have id ``u1000`` and all files in their home directory
are owned by ``u1000`` whereas at uni or work they have login id ``u1125``.

Taking their home directory with them becomes problematic. They can't easily
access their files, they might not be able to write to disk without applying
lax permissions or ACLs and even if they can, they will end up with an annoying
mix of files and directories owned by ``u1000`` and ``u1125``.

Idmapped mounts allow to solve this problem. A user can create an idmapped
mount for their home directory on their work computer or their computer at home
depending on what ownership they would prefer to end up on the portable storage
itself.

Let's assume they want all files on disk to belong to ``u1000``. When the user
plugs in their portable storage at their work station they can setup a job that
creates an idmapped mount with the minimal idmapping ``u1000:k1125:r1``. So now
when they create a file the kernel performs the following steps we already know
from above:::

 caller id:            u1125
 caller idmapping:     u0:k0:r4294967295
 filesystem idmapping: u0:k0:r4294967295
 mount idmapping:      u1000:v1125:r1

1. Map the caller's userspace ids into kernel ids in the caller's idmapping::

    make_kuid(u0:k0:r4294967295, u1125) = k1125

2. Translate the caller's VFS id into a kernel id in the filesystem's
   idmapping::

    mapped_fsuid(v1125):
      /* Map the VFS id up into a userspace id in the mount's idmapping. */
      from_kuid(u1000:v1125:r1, v1125) = u1000

      /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
      make_kuid(u0:k0:r4294967295, u1000) = k1000

3. Verify that the caller's filesystem ids can be mapped to userspace ids in the
   filesystem's idmapping::

    from_kuid(u0:k0:r4294967295, k1000) = u1000

So ultimately the file will be created with ``u1000`` on disk.

Now let's briefly look at what ownership the caller with id ``u1125`` will see
on their work computer:

::

 file id:              u1000
 caller idmapping:     u0:k0:r4294967295
 filesystem idmapping: u0:k0:r4294967295
 mount idmapping:      u1000:v1125:r1

1. Map the userspace id on disk down into a kernel id in the filesystem's
   idmapping::

    make_kuid(u0:k0:r4294967295, u1000) = k1000

2. Translate the kernel id into a VFS id in the mount's idmapping::

    i_uid_into_vfsuid(k1000):
      /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
      from_kuid(u0:k0:r4294967295, k1000) = u1000

      /* Map the userspace id down into a VFS id in the mounts's idmapping. */
      make_kuid(u1000:v1125:r1, u1000) = v1125

3. Map the VFS id up into a userspace id in the caller's idmapping::

    k1125 = vfsuid_into_kuid(v1125)
    from_kuid(u0:k0:r4294967295, k1125) = u1125

So ultimately the caller will be reported that the file belongs to ``u1125``
which is the caller's userspace id on their workstation in our example.

The raw userspace id that is put on disk is ``u1000`` so when the user takes
their home directory back to their home computer where they are assigned
``u1000`` using the initial idmapping and mount the filesystem with the initial
idmapping they will see all those files owned by ``u1000``.