Skip to content
Snippets Groups Projects
  • Linus Torvalds's avatar
    9b93f506
    Merge tag 'fs.idmapped.mnt_idmap.v6.2' of... · 9b93f506
    Linus Torvalds authored
    Merge tag 'fs.idmapped.mnt_idmap.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping
    
    Pull idmapping updates from Christian Brauner:
     "Last cycle we've already made the interaction with idmapped mounts
      more robust and type safe by introducing the vfs{g,u}id_t type. This
      cycle we concluded the conversion and removed the legacy helpers.
    
      Currently we still pass around the plain namespace that was attached
      to a mount. This is in general pretty convenient but it makes it easy
      to conflate namespaces that are relevant on the filesystem - with
      namespaces that are relevent on the mount level. Especially for
      filesystem developers without detailed knowledge in this area this can
      be a potential source for bugs.
    
      Instead of passing the plain namespace we introduce a dedicated type
      struct mnt_idmap and replace the pointer with a pointer to a struct
      mnt_idmap. There are no semantic or size changes for the mount struct
      caused by this.
    
      We then start converting all places aware of idmapped mounts to rely
      on struct mnt_idmap. Once the conversion is done all helpers down to
      the really low-level make_vfs{g,u}id() and from_vfs{g,u}id() will take
      a struct mnt_idmap argument instead of two namespace arguments. This
      way it becomes impossible to conflate the two removing and thus
      eliminating the possibility of any bugs. Fwiw, I fixed some issues in
      that area a while ago in ntfs3 and ksmbd in the past. Afterwards only
      low-level code can ultimately use the associated namespace for any
      permission checks. Even most of the vfs can be completely obivious
      about this ultimately and filesystems will never interact with it in
      any form in the future.
    
      A struct mnt_idmap currently encompasses a simple refcount and pointer
      to the relevant namespace the mount is idmapped to. If a mount isn't
      idmapped then it will point to a static nop_mnt_idmap and if it
      doesn't that it is idmapped. As usual there are no allocations or
      anything happening for non-idmapped mounts. Everthing is carefully
      written to be a nop for non-idmapped mounts as has always been the
      case.
    
      If an idmapped mount is created a struct mnt_idmap is allocated and a
      reference taken on the relevant namespace. Each mount that gets
      idmapped or inherits the idmap simply bumps the reference count on
      struct mnt_idmap. Just a reminder that we only allow a mount to change
      it's idmapping a single time and only if it hasn't already been
      attached to the filesystems and has no active writers.
    
      The actual changes are fairly straightforward but this will have huge
      benefits for maintenance and security in the long run even if it
      causes some churn.
    
      Note that this also makes it possible to extend struct mount_idmap in
      the future. For example, it would be possible to place the namespace
      pointer in an anonymous union together with an idmapping struct. This
      would allow us to expose an api to userspace that would let it specify
      idmappings directly instead of having to go through the detour of
      setting up namespaces at all"
    
    * tag 'fs.idmapped.mnt_idmap.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping:
      acl: conver higher-level helpers to rely on mnt_idmap
      fs: introduce dedicated idmap type for mounts
    9b93f506
    History
    Merge tag 'fs.idmapped.mnt_idmap.v6.2' of...
    Linus Torvalds authored
    Merge tag 'fs.idmapped.mnt_idmap.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping
    
    Pull idmapping updates from Christian Brauner:
     "Last cycle we've already made the interaction with idmapped mounts
      more robust and type safe by introducing the vfs{g,u}id_t type. This
      cycle we concluded the conversion and removed the legacy helpers.
    
      Currently we still pass around the plain namespace that was attached
      to a mount. This is in general pretty convenient but it makes it easy
      to conflate namespaces that are relevant on the filesystem - with
      namespaces that are relevent on the mount level. Especially for
      filesystem developers without detailed knowledge in this area this can
      be a potential source for bugs.
    
      Instead of passing the plain namespace we introduce a dedicated type
      struct mnt_idmap and replace the pointer with a pointer to a struct
      mnt_idmap. There are no semantic or size changes for the mount struct
      caused by this.
    
      We then start converting all places aware of idmapped mounts to rely
      on struct mnt_idmap. Once the conversion is done all helpers down to
      the really low-level make_vfs{g,u}id() and from_vfs{g,u}id() will take
      a struct mnt_idmap argument instead of two namespace arguments. This
      way it becomes impossible to conflate the two removing and thus
      eliminating the possibility of any bugs. Fwiw, I fixed some issues in
      that area a while ago in ntfs3 and ksmbd in the past. Afterwards only
      low-level code can ultimately use the associated namespace for any
      permission checks. Even most of the vfs can be completely obivious
      about this ultimately and filesystems will never interact with it in
      any form in the future.
    
      A struct mnt_idmap currently encompasses a simple refcount and pointer
      to the relevant namespace the mount is idmapped to. If a mount isn't
      idmapped then it will point to a static nop_mnt_idmap and if it
      doesn't that it is idmapped. As usual there are no allocations or
      anything happening for non-idmapped mounts. Everthing is carefully
      written to be a nop for non-idmapped mounts as has always been the
      case.
    
      If an idmapped mount is created a struct mnt_idmap is allocated and a
      reference taken on the relevant namespace. Each mount that gets
      idmapped or inherits the idmap simply bumps the reference count on
      struct mnt_idmap. Just a reminder that we only allow a mount to change
      it's idmapping a single time and only if it hasn't already been
      attached to the filesystems and has no active writers.
    
      The actual changes are fairly straightforward but this will have huge
      benefits for maintenance and security in the long run even if it
      causes some churn.
    
      Note that this also makes it possible to extend struct mount_idmap in
      the future. For example, it would be possible to place the namespace
      pointer in an anonymous union together with an idmapping struct. This
      would allow us to expose an api to userspace that would let it specify
      idmappings directly instead of having to go through the detour of
      setting up namespaces at all"
    
    * tag 'fs.idmapped.mnt_idmap.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping:
      acl: conver higher-level helpers to rely on mnt_idmap
      fs: introduce dedicated idmap type for mounts