setrlimit failure on aarch64 (was: Interesting failure on aarch64)

[Todd Zullinger]

Werner Koch via Gnupg-users wrote:
> On Fri, 20 Dec 2019 11:22, Konstantin Ryabitsev said:
> 
>> On x86_64 this succeeds, but when I tried building on aarch64, that step 
> [...]
>>   gpg: Fatal: can't disable core dumps: Operation not permitted
> 
> setrlimit returns an unexpected error code:
> 
>     if (getrlimit (RLIMIT_CORE, &limit))
>       limit.rlim_max = 0;
>     limit.rlim_cur = 0;
>     if( !setrlimit (RLIMIT_CORE, &limit) )
> 	return 0;
>     if( errno != EINVAL && errno != ENOSYS )
> 	log_fatal (_("can't disable core dumps: %s\n"), strerror(errno) );
> 
> This is the first time I see a report that EPERM is returned.

The getrlimit call also fails, according to strace:

getrlimit(RLIMIT_CORE, 0xffffeb2acf88)  = -1 EPERM (Operation not permitted)
setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = -1 EPERM (Operation not permitted)

I don't have access to an aarch64 host running RHEL 7
directly, so my only testing is via the mock command from an
aarch74 Fedora 31 host.

Mock can use two styles of container, an old-style chroot or
new-style systemd-nspawn.  Using chroot succeeds, while
systemd-nspawn fails.

I tested with CAP_SYS_RESOURCE added to the capability list
in the systemd-nspawn call, without success.  From my
reading, that should work (thought shouldn't be needed as
we're not trying to raise the limit).

So it seems like a bug either in systemd-nspawn or a lower
level component like glibc or the kernel with RHEL 7 on
aarch64, as you suggested.

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200202/b508b411/attachment.sig>