@giuseppe WDYT?

I think it is a great idea, and crun already supports it.

@danishprakash would you like to work on a patch to add this functionality?

I am not sure if it should be done automatically in the way Docker does, or if it should be an explicit flag like rro. @containers/podman-maintainers opinions?

It feels like it ought to be the default, but we should also have the ability to turn it off via volume options

I think the fact that :ro does not apply to child mounts violates POLA and given if one sets ro they likely want the security that this means a container cannot modify the content there so I think it would be a net win if ro is treated as rro on the kernel side.

Of course backwards compatibility is tricky with that behavior. If we need a why out what should we name such a option norro? And then I think we still must support older kernels right so we need some kind of feature checks which kind of suck IMO. I really hate these kernel version checks. I guess we could try a stub mount as well then cache it as file?

@giuseppe Do the oci runtimes crun/runc just hard error if we request rro and the kernel has no support for it?

@giuseppe Do the oci runtimes crun/runc just hard error if we request rro and the kernel has no support for it?

yes, if we request rro and that cannot be honored then the OCI runtimes fail. A fallback to ro would be a security issue, since it loosens the configuration.

I think the fact that :ro does not apply to child mounts violates POLA and given if one sets ro they likely want the security that this means a container cannot modify the content there so I think it would be a net win if ro is treated as rro on the kernel side.

fair. Then we could have a check like containers/storage does for several kernel features and convert ro to rro when supported.

@danishprakash would you like to work on a patch to add this functionality?

Yes, I can pick this up.

I agree that this should be the default, but given that backwards compatibility is going to be an issue, we can perhaps consider the approach taken by mount(8), they introduced ro=recursive syntax to get out of a similar situation[1]. This might be a way out but the default ro (non-recursive) still remains a security concern imo.

[1] - util-linux/util-linux#1501

A friendly reminder that this issue had no activity for 30 days.

@danishprakash still interested to work on this issue?

Yes @giuseppe, just got back to it yesterday. Sorry about the long silence on this.

Do we have a provision for a list of supported feature by the runtime--[crun|runc] features? Of course, there's cmd out, but I feel this might be a useful addition to cache runtime features. One possible way could be to have ContainerRuntime[Config|Features] within SpecGenerator and use it down the stack, but I'm not sure if that's the right place for it.

we could cache the result of $OCI_RUNTIME features in the rundir

How about fetching and caching the features as part of newConmonOCIRuntime() before returning an OCIRuntime unmarshalled onto opencontainers/runtime-spec/specs-go/features? That's similar to how docker does it and sounds like the right place to plug this into.

yes, that seems like a good place to me

Storing features in the runtime is fine, but using that while generating the spec isn't as straightforward given that we don't have access to the runtime while we create the spec. Possibilities include:

• pass in the runtime but that seems wrong
• request the default runtime again
• simply figure out the runtime of choice from within specgen and parse it locally to figure out whether the runtime supports a certain feature--rro in this case--or not.

Ideally, I would have loved for the runtime to be available while parsing the spec so as to be able to appropriately generate the spec. Docker does this currently and I believe this would also be extensible in the future if we need to consult with the runtime while we creating the spec. Thoughts?

• pass in the runtime but that seems wrong

Given the alternatives, I'd do this. Why do you think it is wrong?

@containers/podman-maintainers any other suggestions?

We don't have a daemon to store a cache and even if we only do it once on first start and write it to the rundir we then would have to always read an unmarshal it (likely not to noticeable but still some overhead). But the IMO worse problem with a cache like this is lifetime. So far we are using this to perform some kernel feature checks which makes sense to have them on tmpfs as a new boot could mean new kernel. However the oci runtime on the other hand might get updated without a reboot. As such we then cache the old features even when a newer runtime with the features might be in use.

Also we support many different runtimes via --runtime so would we not have to cache the features for every single one of them? Doing this properly will get much more complicated.

Kernel 5.12 is quite old now, could be just set this as baseline for our support an always add rro? What oci runtime versions started to support rro? AFAIK it doesn't only depend on the kernel version as the runtimes must set it via mount_setattr()?
People who can update podman should also be able to update its dependencies such as runtime and kernel.

As far as specgen generation goes I think it would be wrong to make decisions based on the runtime.
We support stuff like podman system migrate --new-runtime to update all existing containers to a new runtime. That of course is a bit questionable in itself with how we do that but if the spec changes based on the runtime then we can later not migrate and assume it still works. (I know assuming that it just works today is also be a bit of a stretch)

If we were to add runtime specific stuff to the spec then IMO it should be part of generateSpec() in libpod and never pkg/specgen. @mheon WDYT?

I agree with @Luap99 - this doesn't sound like a Specgen thing, but a generateSpec() thing. Features that are runtime-dependent should be added at that point in the process, where we are absolutely sure what runtime is in use, what version of the runtime is in use, and what kernel version is in use. We have access to the completed OCI runtime at that point, so if we cache the features in the runtime they are easily accessible.