ovl: document security.capability idmapping on the xattr forward paths

Now that an overlay mount can itself be idmapped, every id exposed at
the overlay-inode boundary is mapped through the overlay mount idmap.
security.capability is the one id-bearing xattr that overlayfs does not
translate in its own boundary code: the embedded rootid of a v3 fscap
is instead mapped by the capability LSM inside vfs_getxattr() and
vfs_setxattr().

It still composes correctly only because the xattr read and write
forwards go through the security-aware vfs_getxattr() / vfs_setxattr()
rather than the raw __vfs_*xattr() variants: commoncap maps the rootid
through the layer idmap at the overlay-to-real forward, while the
overlay mount idmap is applied by the outer vfs_getxattr() at the
syscall boundary, mirroring the layer-then-mount composition used by
ovl_getattr().

The raw __vfs_*xattr() variants skip the security hooks and would
silently drop the rootid mapping. Comment both forwards - the read in
ovl_xattr_get() and the write in ovl_do_setxattr() - so they are not
converted to them by accident.

No functional change.

Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-10-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

0 files changed, 0 insertions, 0 deletions