utils: ignore ENOTSUP when chmod a symlink

[giuseppe]

commit 5d1f903f75a80daa4dfb3d84e114ec8ecbf29956 in the kernel, present in a release since Linux 6.6 doesn't allow anymore to change the mode of a symlink, so just ignore the failure.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d1f903f75a80daa4dfb3d84e114ec8ecbf29956

Closes: #1308

[flouthoc]

LGTM , just a small question above.

[Luap99]

Did you ask on the kernel list to revert or at least not backport this change?
I am asking because the linked commit asked for backports to stable releases which means this will start breaking on older LTS releases unless crun gets updated there which seems unlikely.

[giuseppe]

no, I've not asked it yet.

@brauner even if the issue is in user space (as in our case), do you think the mentioned patch "attr: block mode changes of symlinks" should be reverted on LTS releases to prevent such kind of errors when the kernel is updated?

[brauner]

no, I've not asked it yet.

@brauner even if the issue is in user space (as in our case), do you think the mentioned patch "attr: block mode changes of symlinks" should be reverted on LTS releases to prevent such kind of errors when the kernel is updated?

I would leave it in the LTS as well to make it consistent what you did above could fail before btw. It depends on the fstype whether this breaks and whether posix acls are enabled or not. That's why this was blocked in the first place as it only works sometimes.

The code you added in there isn't guaranteed to work and why both glibc and musl removed it. If you want to insist on it getting reverted from the LTS than you can probably get Greg to do this but if you can live with fixing this up here we're all better off imho.

[kolyshkin]

LGTM

NB1: ENOTSUP == EOPNOTSUPP in glibc (but not in the kernel).

NB2: The code to handle ENOTSUP was added in 2019 in commit 805e01d.

Later in 2020, glibc added its own handling of AT_SYMLINK_NOFOLLOW to its fchmodat, and it returns EOPNOTSUPP in case of a symlink. This was added by https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c (see also https://sourceware.org/bugzilla/show_bug.cgi?id=14578) and is there since glibc-2.32.

I think musl did a similar change but haven't took a closer look.

[edsantiago]

@giuseppe do you have a guess on when this will hit bodhi?

[giuseppe]

today! :)

[aki-k]

This issue occurs with kernel 6.5.5 too (podman container with systemd)

[adworacz]

This issue is now effecting Debian stable, which updated its kernel to 6.1.0-13 (6.1.55), which includes the backported change, as you can see in this change log.

This is breaking some of my podman containers on my Debian install.

https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.55+1_changelog

[aki-k]

I received an update crun-1.9.2-1.fc37 (Fedora 37) today and now systemd in a podman container works again.

Kernel 6.5.6-100.fc37.x86_64

[christianhorn]

I see this on Fedora39 with all updates as of today, on aarch64 and x86_64.
kernels 6.5.6-300.fc39.x86_64 and 6.5.6-403.asahi.fc39.aarch64+16k
podman and crun versions are same on both systems:

[chris@asahi ~]$ podman --version
podman version 4.7.0
[chris@asahi ~]$ crun --version
crun version 1.9
commit: a538ac4ea1ff319bcfe2bf81cb5c6f687e2dc9d3
rundir: /run/user/1000/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL

Reproduces in a newly deployed Fed39 KVM guest on x86_64: I used 'podman build [..]' to build an image (based on Debian Bookworm in my case) and then 'podman run':

[chris@fed39 ~]$ podman run --privileged -p 127.0.0.1:8084:80 --name mastodon -d \
   --security-opt seccomp=unconfined      localhost/mastodon /lib/systemd/systemd
Error: OCI runtime error: crun: chmod `run/shm`: Operation not supported