Hard links losing ownership information when run with user namespaces #1257
Comments
|
when we create a container based on a remapped image we lose all the data overlay stored internally in the @rhvgoyal how can we reuse as a lower dir an overlay mount that uses What we would like to achieve it is to create a copy of an image (where we chown files accordingly to the user namespace configuration), and use that as a base for containers using that mapping. @nalind PTAL |
|
my mistake, In this case I think it is expected behavior and it behaves as documented for the overlay file system: and it breaks the hard link. So I need to fixup #1144 to consider this case |
Add an additional check before deciding whether the chown must be skipped. If the underlying storage (as it could be overlay with index=off) breaks the hard link on copy up then we cannot skip the chown even if the dev/ino was already encountered. containers#1144 added the initial check. Closes: containers#1257 Signed-off-by: Giuseppe Scrivano <[email protected]>
|
PR here: #1258 It doesn't fix the case where |
|
I've tested the patch at #1258 in a scratch build for F36 available at https://koji.fedoraproject.org/koji/taskinfo?taskID=88236616, and it has fixed the issue for me! |
If the inode was already encountered and chowned, use link(2) instead of chown(2). This is needed when the underlying storage (as it could be overlay with index=off) breaks the hard link on copy up. containers#1144 added the initial check. Closes: containers#1257 Signed-off-by: Giuseppe Scrivano <[email protected]>
If the inode was already encountered and chowned, use link(2) instead of chown(2). This is needed when the underlying storage (as it could be overlay with index=off) breaks the hard link on copy up. containers#1144 added the initial check. Closes: containers#1257 Signed-off-by: Giuseppe Scrivano <[email protected]>
|
@giuseppe I am not sure I understand what's the problem with index=on. My understanding is that you will download an image layers, create union using overlayfs (with index=on) and then do chown. Hardlinks will not be broken as index=on has been used. Now will you not use this overlay as lower for next overlay mount for container. I think all the metadata index is in workdir/index dir and underlying overlayfs will understand that and report link count, and inode numbers etc correctly. If you are trying to get rid of lower overlay and move reusing upper/ as a lower dir for container overlayfs that probably will be a problem. |
If the inode was already encountered and chowned, use link(2) instead of chown(2). This is needed when the underlying storage (as it could be overlay with index=off) breaks the hard link on copy up. containers#1144 added the initial check. Closes: containers#1257 Signed-off-by: Giuseppe Scrivano <[email protected]>
If the inode was already encountered and chowned, use link(2) instead of chown(2). This is needed when the underlying storage (as it could be overlay with index=off) breaks the hard link on copy up. containers#1144 added the initial check. Closes: containers#1257 Signed-off-by: Giuseppe Scrivano <[email protected]>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When running containers with user namespaces (either using
--uidmapor--userns=auto), ownership isn't set correctly for some hardlinks. The original file has the correct ownership, but any links belong tonobody.nobody.Steps to reproduce the issue:
Describe the results you received:
Notice that a number of the files are owned by
nobody.nobodywhen running with--userns=auto, but those same files are owned byroot.rootorroot.namedwhen run without user namespaces.Describe the results you expected:
Ownership should be the same (
root.rootorroot.named) whether running with or without user namespacesAdditional information you deem important (e.g. issue happens only occasionally):
This does seem to be tied to hard links in the containers.
freeipadoes some interesting things with hardlinks, and you end up with 3 or 4 hard links of these configuration files. It's only the files with hard links that seem to be having this problem.In this example, the hard links are created as part of the build process, not in an entrypoint.
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Physical machine running Fedora 36
The text was updated successfully, but these errors were encountered: