docs: filesystems: idmappings: clarify from where idmappings are taken

Let's clarify from where we take idmapping of each type:
- caller
- filesystem
- mount

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Message-Id: <20230625182047.26854-1-aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This commit is contained in:
Alexander Mikhalitsyn 2023-06-25 20:20:47 +02:00 committed by Christian Brauner
parent 8a237adf21
commit d220efa20b

View File

@ -373,6 +373,13 @@ 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