oci: ignore system.nfs4_acl and extend forbidden-xattr handling

[cyphar]

It turns out that system.nfs4_acl is yet another xattr that we shouldn't
be touching, but also that we should not be clearing (while we have
permission to do so, clearing it results in NFS permissions breaking).
So as an extension we now now use ignoreXattrs for both unpack and
repack operations.

Closes #248
Signed-off-by: Aleksa Sarai asarai@suse.de

[cyphar]

Alright, this should fix the issue. @besnardjb did you want to test this?

[besnardjb]

Hi @cyphar,

Thank you very much for the pull request, it is indeed much cleaner.

I've made a quick test on the Centos OCI image (from docker) and the NFS part is solved for me when extracting on shared FS with your configurable filter.

However, I've encountered another attribute (user.rootlesscontainers) in this same image. As a consequence, I still fail on lsetxattr as attributes are not supported on the target file-system (details below).

Here is how it failed and how I got there:

$ mount | grep raid
(...):/media/raid on /media/raid type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.19.213.42,local_lock=none,addr=10.19.213.127)
$ pwd
/media/raid/phomes/jbbesnard/(...)/umoci
$ git describe                                                                                           
v0.4.1-19-gaa8200d
$ skopeo copy docker://centos oci:centos:latest
(...)
$ LANG=us strace -f -e trace=lsetxattr ./umoci --log debug  unpack --rootless --image ./centos ./centos_bundle
(...)
   • rootless{run/} ignoring forbidden xattr: "system.nfs4_acl"
   • unpacking entry           path=run/lock root=centos_bundle/rootfs type=53
   • rootless{run/} ignoring forbidden xattr: "system.nfs4_acl"
   • unpacking entry           path=run/lock/lockdev root=centos_bundle/rootfs type=53
[pid  4563] lsetxattr("centos_bundle/rootfs/run/lock/lockdev", "user.rootlesscontainers", "\10\377\377\377\377\17\0206", 8, 0) = -1 EOPNOTSUPP (Operation not supported)
   • rootless{lock/} ignoring forbidden xattr: "system.nfs4_acl"
   ⨯ create runtime bundle: unpack rootfs: unpack layer: unpack entry: run/lock/lockdev: apply hdr metadata: restore xattr metadata: centos_bundle/rootfs/run/lock/lockdev: unpriv.lsetxattr: operation not supported
(...)
+++ exited with 1 +++
#Same on alpine:
[pid  4956] lsetxattr("alpine_bundle/rootfs/etc/shadow", "user.rootlesscontainers", "\10\377\377\377\377\17\20*", 8, 0) = -1 EOPNOTSUPP (Operation not supported)

As my FS returns EOPNOTSUPP on such calls, I fail on extracting the image. In fact, it seems that exrtended attributes are not supported on NFS v4.

So (and to my knowledge) I see some ways here:

• I manually add "user.rootlesscontainers" to the ban list as I'm on NFS but it would surely be useful on systems supporting it;
• Add a flag basically telling "do your best I WANT this rootfs at all costs" 🤣 -- permissive;
• As the target FS says that it does not support xattrs (EOPNOTSUPP) umoci emits a warning that information is being lost and just keep going on.

The later was my strategy here (besnardjb@612c1d2) although the implementation is clearly disputable 😄 !

// On NFS altering extended attrs may not be supported
if errors.Cause(err).Error() == "operation not supported" {
    continue
}

Thanks for your great work !

I remain available.

Cheers.

[cyphar]

Ah okay. Yeah, we should ignore (but print a warning) on ENOTSUP. The string comparison is not the best way of doing it -- but I do understand what you mean. I'll work on an updated patch for that.

[cyphar]

Okay, I've pushed a new patch that should fix it. Ignore the test failure, I'm working on that separately.

[besnardjb]

I confirm this solved my issue on both images for an NFS extract. Thanks!

[cyphar]

Cool. I will merge this as soon as I've bumped the test coverage enough to make the tests succeed again. I'll also make a new release soon (sometime next week hopefully).

[cyphar]

LGTM.