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

2020-02-02 Thread Todd Zullinger via Gnupg-users 
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.rlim_max = 0;
> limit.rlim_cur = 0;
> if( !setrlimit (RLIMIT_CORE, ) )
>   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, 0xeb2acf88)  = -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

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

2020-01-20 Thread Werner Koch via Gnupg-users 
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.rlim_max = 0;
limit.rlim_cur = 0;
if( !setrlimit (RLIMIT_CORE, ) )
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.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users