summaryrefslogtreecommitdiff
path: root/drivers/phy/axiado/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2026-06-15 15:19:55 +0200
committerChristian Brauner <brauner@kernel.org>2026-06-29 10:32:32 +0200
commitadedb6a00a1e4c77b1de9ea1f63b5008ad0c21f5 (patch)
tree5577cfdc60bfe72a041026262033b18ff931da31 /drivers/phy/axiado/git@git.tavy.me:linux.git
parentd1f78a3fed4a949db70205719d4b17d97f5e95c0 (diff)
ovl: allow idmapping overlay mounts
Now that every overlay inode operation honors the overlay mount idmap, allow the merged overlay mount itself to be idmapped by setting FS_ALLOW_IDMAP on ovl_fs_type. mount_setattr(MOUNT_ATTR_IDMAP) can then apply an idmapping to an overlay mount, exposing the merged tree under a different ownership view. The composition is clean because overlayfs already normalizes every underlying id through the relevant layer idmap when it copies attributes into the overlay inode (ovl_copyattr()); the overlay inode's i_{u,g}id are thus "overlay-final" ids. The overlay mount idmap composes on top of that pivot: it is applied to (getattr) and removed from (setattr, create) those ids at the overlay-inode boundary - permission, getattr, setattr, ACL owner checks and inode_init_owner() - while the underlying layers keep being accessed with the mounter's credentials through their own, possibly idmapped, mounts. The mount idmap therefore only changes how the caller sees the overlay inode and never widens the mounter's access to the layers. This is deliberately the final code patch of the series: only once every operation honors the mount idmap is it safe to make overlay mounts idmappable. Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-6-7381632aa402@kernel.org Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'drivers/phy/axiado/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions