Bug #9600

sysconf(_SC_GETGR_R_SIZE_MAX) is just a hint for getgrnam_r()

Added by Rei Odaira about 1 year ago. Updated 9 months ago.

[ruby-core:61325]
Status:Closed
Priority:Normal
Assignee:-
ruby -v:ruby 2.2.0dev (2014-03-05) [powerpc64-linux] Backport:1.9.3: REQUIRED, 2.0.0: DONE, 2.1: DONE

Description

When there is a group that has a lot of members, TestProcess#test_execopts_gid fails. Following is a more simple example:

$ ruby -e 'system("true", gid: "largegroup")'
-e:1:in `system': Numerical result out of range - getgrnam_r (Errno::ERANGE)
from -e:1:in `<main>'

This wrong exception happens because obj2gid() in process.c calls getgrnam_r() with a buffer that was allocated based on the size returned by sysconf(SC_GETGR_R_SIZE_MAX). In Linux, sysconf(_SC_GETGR_R_SIZE_MAX) returns 1024, but actually this value is just a hint, so obj2gid() should gradually extend the buffer until getgrnamr() no longer throws ERANGE.

The same issue was reported in the following page:
http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r-getgrnam_r/

Associated revisions

Revision 45290
Added by Nobuyoshi Nakada about 1 year ago

process.c: expand buffer on ERANGE

  • process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r() may need larger buffers than sysconf values, so retry with expanding the buffer when ERANGE is returned. [Bug #9600]

Revision 45290
Added by Nobuyoshi Nakada about 1 year ago

process.c: expand buffer on ERANGE

  • process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r() may need larger buffers than sysconf values, so retry with expanding the buffer when ERANGE is returned. [Bug #9600]

Revision 46449
Added by Tomoyuki Chikanaga 10 months ago

merge revision(s) r45287,r45288,r45289,r45290: [Backport #9600]

process.c: tmp buffer instead of alloca

* process.c (OBJ2UID1, OBJ2GID1): separate from OBJ2UID and

OBJ2GID respectively, need given buffers.

* process.c (OBJ2UID, OBJ2GID): no longer need PREPARE_GETPWNAM

and PREPARE_GETGRNAM.

* process.c (obj2uid, obj2gid): use tmp buffer instead of alloca

to get rid of potential stack overflow.
* process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r()
may need larger buffers than sysconf values, so retry with
expanding the buffer when ERANGE is returned.
[Bug #9600]

Revision 46511
Added by Usaku NAKAMURA 9 months ago

merge revision(s) 45287:45290: [Backport #9600]

* process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r()
  may need larger buffers than sysconf values, so retry with
  expanding the buffer when ERANGE is returned.
   [Bug #9600]

History

#1 Updated by Nobuyoshi Nakada about 1 year ago

Isn't there any way to get the real number?

#2 Updated by Yui NARUSE about 1 year ago

Rei Odaira wrote:

but actually this value is just a hint, so obj2gid() should gradually extend the buffer until getgrnam_r() no longer throws ERANGE.

SuSv7 changes it.

SD5-XSH-ERN-166 is applied, changing "Maximum size" to "Initial size" for the "Maximum size of ..." entries in the table in the DESCRIPTION.

But I didn't find SD5-XSH-ERN-166 itself.

#3 Updated by Akira Tanaka about 1 year ago

Off topic.

Yui NARUSE wrote:

SuSv7 changes it.

There is no Single Unix Specification version 7 (yet).
The issue number is not the version number.

SUSv3:
| The Single UNIX Specification, Version 3 is made up of the Base Specifications, Issue 6 and
| X/Open Curses, Issue 4, Version 2.
http://www.unix.org/version3/sus_contents.html

SUSv4:
| The Single UNIX Specification uses The Open Group Base Specifications, Issue 7 documentation as its core.
| The documentation is structured as follows:
| * The Base Specifications, Issue 7, composed of:
| - Base Definitions, Issue 7 (XBD7)
| - System Interfaces, Issue 7 (XSH7)
| - Shell and Utilities, Issue 7 (XCU7)
| - Rationale, Issue 7, (XRAT7) (Informative)
| * X/Open Curses, Issue 7
http://www.unix.org/version4/overview.html

#4 Updated by Daniel Berger about 1 year ago

I don't think there's a way to get it. You'll have to rescue and retry with a realloc'ed buffer.

One bit of trickiness is that different platforms seem to set errno to different values on different platforms. In my own sys-admin gem, I caught Errno::ERANGE on Linux and Solaris, while on Darwin it was Errno::ENOENT, and on FreeBSD it was Errno::ENOTTY.

#5 Updated by Nobuyoshi Nakada about 1 year ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Applied in changeset r45290.


process.c: expand buffer on ERANGE

  • process.c (obj2uid, obj2gid): now getpwnam_r() and getgrnam_r() may need larger buffers than sysconf values, so retry with expanding the buffer when ERANGE is returned. [Bug #9600]

#6 Updated by Rei Odaira 12 months ago

Wouldn't it be possible to backport this to 2.0.0 and 2.1, where the same issue resides?

#7 Updated by Yui NARUSE 12 months ago

  • Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED

#8 Updated by Tomoyuki Chikanaga 10 months ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE

r45287, r45288, r45289 and r45290 were backported into ruby_2_1 branch at r46449.

#9 Updated by Usaku NAKAMURA 9 months ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE to 1.9.3: REQUIRED, 2.0.0: DONE, 2.1: DONE

backported into ruby_2_0_0 at r46511.

Also available in: Atom PDF