features: mountExtensions: how best to represent feature support for idmap? #1223

Activity

1. cyphar commented on Aug 23, 2023

   

   cyphar

   on Aug 23, 2023

   MemberAuthor

   More actions

   Maybe this could be an object like:

   "mountExtensions": {
     "idmap": {
       "modes": ["sameAsUserns", "arbitrary"],
       "filesystemTypes": ["ext4", "tmpfs", "foobarfs"],
       "supportsBind": true
     }
   }
   

   wdyt?

   Also we need to figure out how to deal with recursive mounts -- see #1216. If we add a separate flag for this, we will need to add an entry to this struct.

   Originally posted by @cyphar in #1219 (comment)
2. cyphar commented on Aug 23, 2023

   

   cyphar

   on Aug 23, 2023

   MemberAuthor

   More actions

   I think having a list of supported (or explicitly unsupported) filesystems would be a good idea. Now that I think about it, since runc will not release a version with restricted mapping support, it's probably not necessary to have a field for whether we support arbitrary mappings or not. I think it's fair to say the spec implies arbitrary mapping support is a requirement.
3. rata commented on Aug 24, 2023

   

   rata

   on Aug 24, 2023

   Last edited by rata

   Member

   More actions

   The parsing of the filesystems at runtime (besides I don't know how you plan to detect idmap mount support at runtime) seems not to be what we should do:

   The Features structure is irrelevant to the actual availability of the features in the host operating system. Hence, the content of the Features structure SHOULD be determined on the compilation time of the runtime, not on the execution time.
4. cyphar commented on Aug 27, 2023

   

   cyphar

   on Aug 27, 2023

   MemberAuthor

   More actions

   besides I don't know how you plan to detect idmap mount support at runtime

   That isn't my proposal -- the plan is to provide a list of filesystems that may work (or we can do it your way -- make a list that definitely don't work). If we want to return a list of filesystems that are definitely not supported (your suggestion), it will be necessary to copy the output of /proc/filesystems for container runtimes that only support bind-mounts (which is currently all OCI runtimes that support is mappings).
5. rata commented on Aug 28, 2023

   

   rata

   on Aug 28, 2023

   Member

   More actions

   @cyphar

   That isn't my proposal -- the plan is to provide a list of filesystems that may work

   Then it won't remove the trial and error that was your use case.

   If we want to return a list of filesystems that are definitely not supported (your suggestion)

   I think that is cleaner, but I don't see any real use case for any of this.

   The only thing I can think of is, if k8s wants to enable userns by default (I'd love to do that), it might be useful to know which things won't work. But not even in this case, as k8s only sets bind-mounts (and I don't think that will change soon), so this is probably not needed in that case either.

   it will be necessary to copy the output of /proc/filesystems for container runtimes that only support bind-mounts

   Hmm, why? I don't see it at all why this won't be just a list of fs we need to change the infrastructure to support idmapping them. Why would we parse that?

   (which is currently all OCI runtimes that support is mappings).

   crun in git now supports regular mounts too.