Bug 22020

Summary: sysconf: Soft limits (such as _SC_ATEXIT_MAX) should not return arbitrary values
Product: glibc Reporter: Florian Weimer <fweimer>
Component: libcAssignee: Paul Pluzhnikov <ppluzhnikov>
Status: NEW ---    
Severity: normal CC: carlos, drepper.fsp, ppluzhnikov
Priority: P2 Flags: fweimer: security-
Version: 2.26   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Florian Weimer 2017-08-28 20:01:15 UTC
glibc defines _SC_ATEXIT_MAX, but this is incorrect according to POSIX.  If the limit is dependent on an unspecified quantity such as available system memory, POSIX says that the constant shall not be defined.

In any case, the return value INT_MAX of sysconf (_SC_ATEXIT_MAX) is bogus.
Comment 1 Carlos O'Donell 2017-08-28 21:11:32 UTC
It's not entirely clear to me what should be returned or what should be defined.

Are you suggesting we remove _SC_ATEXIT_MAX from limits.h, as the standard suggests, for indeterminate limits?

If that is your suggestion, then we would need some way to verify that we always have 32 atexit slots, since the limit removal is conditional on always meeting the minimum.
Comment 2 Paul Pluzhnikov 2017-09-02 21:54:23 UTC
32 slot limit is now tested:

https://sourceware.org/git/?p=glibc.git;a=commit;h=50c66c7acd90f257b295e58bf938ed120cbc27c7
https://sourceware.org/git/?p=glibc.git;a=commit;h=3824fc38910f71c2c8cc623e788ff7eb09999642

I'll mail a patch to delete the _SC_ATEXIT_MAX define.

> what should be returned

quoting http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html:

  If the variable corresponding to name has no limit, sysconf() shall return -1 without changing the value of errno.

I'll send a patch.
Comment 3 Paul Pluzhnikov 2017-09-02 22:53:51 UTC
This seems to be much bigger problem than just _SC_ATEXIT_MAX:

1. we #define all kinds of other limits: _SC_ARG_MAX, _SC_THREADS, etc.
2. for all of them, we return -1 from getconf (good) while setting errno to ENOSYS (bad).
2. we have no tests for any of this.
Comment 4 joseph@codesourcery.com 2017-09-04 15:54:08 UTC
As far as I can tell, the names such as _SC_ATEXIT_MAX *should* be defined 
unconditionally; it's names such as ATEXIT_MAX that are omitted when the 
limits are variable.  What's the basis for saying _SC_ATEXIT_MAX should be 
omitted?
Comment 5 Florian Weimer 2017-09-18 14:04:59 UTC
(In reply to joseph@codesourcery.com from comment #4)
> As far as I can tell, the names such as _SC_ATEXIT_MAX *should* be defined 
> unconditionally; it's names such as ATEXIT_MAX that are omitted when the 
> limits are variable.  What's the basis for saying _SC_ATEXIT_MAX should be 
> omitted?

Yes, your are probably rgiht.  I adjusted the summary based on your comment and Paul's in comment 3.
Comment 6 Paul Pluzhnikov 2017-09-18 15:06:30 UTC
I'll mail a patch soon.