Commit d220efa2 authored by Alexander Mikhalitsyn's avatar Alexander Mikhalitsyn Committed by Christian Brauner
Browse files

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: default avatarAlexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Message-Id: <20230625182047.26854-1-aleksandr.mikhalitsyn@canonical.com>
Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
parent 8a237adf

Documentation/filesystems/idmappings.rst

+7 −0
Original line number Diff line number Diff line
@@ -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