storage, overlay: use openat2 instead of using procfs

[giuseppe]

No description provided.

[jankaluza]

I'm thinking if we should be more specific here and only continue on certain errors. Previous code, using Getxattr for example returned an error in case the path did not exist or couldn't be opened, while the code introduced in this PR ignores these issues.

I don't have a strong opinion, just something to think about.

[giuseppe]

you are right, we should ignore only ENOENT. I'll fix it

[kolyshkin]

Yes, this was previously noted by @cgwalters somewhere in #651 (although I can't find it now; github is terrible in that regard).

[kolyshkin]

Ah! There was also a comment from @cgwalters about RESOLVE_NO_SYMLINKS -- this might be a change in behavior here -- intermediate symlinks were followed before and are not followed now.

Or are we sure we do not use symlinks here at all?

[mtrmac]

I think a reasonable reading of https://github.com/opencontainers/image-spec/blob/main/layer.md implies that layers never refer to files by paths that indirect through symlinks (and certainly that’s the only reasonable way to implement creating layers from diffs), but the spec doesn’t quite say so explicitly.

I’m personally very comfortable with enforcing that assumption .

[jankaluza]

LGTM once you address the issue with ignoring the openat2 errors (either by fixing or acknowledging in the comment).

[mtrmac]

Thanks!

[Luap99]

I assume this code path was not tested, my simple vendor PR is failing:

# podman [options] --pull-option=enable_partial_images=true --pull-option=convert_images=true save -o /var/tmp/quay.io-libpod-cirros-latest.tar quay.io/libpod/cirros:latest
Copying blob sha256:b993cfcfd8fdc2731b308222fce8b5ce7a681780ab276b6a23e1b0fe3ce06bbb
Copying blob sha256:aa107a40759291c596cd432ca14cf15e781b91cf82121dc5a335eb734cafe1c4
Copying blob sha256:858d98ac489379d0c34c20811558091180c724d7d185693c3a601ba8c0a1cedf
Error: reading blob sha256:b993cfcfd8fdc2731b308222fce8b5ce7a681780ab276b6a23e1b0fe3ce06bbb: fgetxattr bin/busybox: bad file descriptor

https://api.cirrus-ci.com/v1/artifact/task/5161488211509248/html/int-podman-rawhide-root-host.log.html

Is it expected that we do not have any code coverage in the storage tests? should there be a overlay + composefs test here as part of the CI matrix?

---

The O_PATH docs are clear that this wont work.

The file itself is not opened, and other file operations (e.g., read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), ioctl(2), mmap(2)) fail with the error EBADF.

I opened a PR #824