#1368 getrlimit() system call fails in epel-7-aarch64 builds.
Closed: External 3 years ago by praiskup. Opened 3 years ago by dwmw2.

I think https://gitlab.com/openconnect/ocserv/-/issues/296 might be a COPR issue.
My epel-7-aarch64 builds are failing because the getrlimit system call is not permitted:
https://download.copr.fedorainfracloud.org/results/dwmw2/openconnect/epel-7-aarch64/01361813-openconnect/build.log.gz

Normally, we'd expect glibc's getrlimit() function actually to use the prlimit system call which replaces both getrlimit and setrlimit system calls. But the aarch64 glibc doesn't use prlimit; it still uses the old separate system calls. Do those need adding to a filter of permitted system calls? Or is it not the COPR environment which is preventing this?


Hello @dwmw2,
thank you for the report.

We already have an existing issue in bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1813089

And it seems to be a kernel issue. I will try to pass it to the kernel guys and we will have to wait.

Metadata Update from @praiskup:
- Issue tagged with: blocked, bug

3 years ago

I would be surprised is this is truly a kernel issue. Even if the kernel didn't support the old getrlimit syscall it would get -ENOSYS not -EPERM. This really looks like something (copr, mock, etc.) has filtered the system calls which are permitted in the container and has neglected to permit getrlimit(), which doesn't matter on other architectures (or indeed newer arm64) where glibc uses the prlimit syscall for that purpose.

It seems this is finally fixed on Fedora 33:
$ rpm -q systemd kernel mock
systemd-246.6-3.fc33.aarch64
package kernel is not installed
mock-2.6-1.fc33.noarch

Thanks for reporting this!

Metadata Update from @praiskup:
- Issue close_status updated to: External
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata