overlay: do not clone source recursively

[giuseppe]

do not clone the source directory in recursive mode (the equivalent of
MS_BIND|MS_RECURSIVE) but use only a regular bind mount. If
not recursive bind mount is used then the existing overlay mounts are
not replicated. In this way a new idmapped mount won't need to map
the overlay mount as well, causing the mount_settattr(2) syscall to
fail with EINVAL since it is not possible to idmap an overlay mount
yet.

Closes: #1308

Signed-off-by: Giuseppe Scrivano gscrivan@redhat.com

[rhatdan]

LGTM
@nalind @flouthoc @vrothberg @TomSweeneyRedHat @umohnani8 @cdoern PTAL

[rhatdan]

@markhuang1212 PTAL and see if this solves your issue.

[markhuang1212]

@markhuang1212 PTAL and see if this solves your issue.

It solved my issue.

[nalind]

Sounds reasonable. Is there a test that exercises this scenario?
The constants defined in idmapped_utils.go are now present in golang.org/x/sys/unix, so we might want to switch to using those definitions.

[flouthoc]

LGTM

[flouthoc]

Sounds reasonable. Is there a test that exercises this scenario?
The constants defined in idmapped_utils.go are now present in golang.org/x/sys/unix, so we might want to switch to using those definitions.

Just waiting for this ^

[giuseppe]

Sounds reasonable. Is there a test that exercises this scenario?
The constants defined in idmapped_utils.go are now present in golang.org/x/sys/unix, so we might want to switch to using those definitions.

I've added another commit that drops these constants.

I am not sure about a test, it is not a new feature just a different way to mount the layers when there are mappings so we are taking advantage of the existing ones. We have not caught the issue in the CI because the new feature requires Linux 5.19 that is currently only available on Rawhide

[rhatdan]

LGTM

[thorstenrie]

Thanks for the fix to #1308. Referring to the comment, and as I understood it, and I hope I didn't get it wrong, it resolves for Arch Linux users with a new release of containers/storage, afterwards including it in podman with a new podman release (for reference, see FS#75605). I would appreciate considering a new containers/storage release to allow it to proceed down to the downstream. Thanks for your consideration and taking the time. Hope you are all safe & best regards