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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
