setrlimit failure on aarch64 (was: Interesting failure on aarch64)
Werner Koch
wk at gnupg.org
Mon Jan 20 15:21:51 CET 2020
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. Disabling
core dumps is an easy and not to invasive security feature. The man gae
for setrlimit mentions this:
EPERM An unprivileged process tried to raise the hard limit; the
CAP_SYS_RESOURCE capability is required to do this.
EPERM The caller tried to increase the hard RLIMIT_NOFILE
limit above the maximum defined by
/proc/sys/fs/nr_open (see proc(5))
We are not increasing the limit so we should not see this error. For
the linux specific prlimit, which we do not use, there is an additional
erro code reason:
EPERM (prlimit()) The calling process did not have permission to
set limits for the process specified by pid.
Next step would be look into glibc and then into aarch64 kernel specific
implementation details of setrlimit.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200120/5beb7feb/attachment.sig>
More information about the Gnupg-users
mailing list