Project

General

Profile

Actions

Bug #9600

closed

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

Added by ReiOdaira (Rei Odaira) over 10 years ago. Updated almost 10 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.2.0dev (2014-03-05) [powerpc64-linux]
[ruby-core:61325]

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 getgrnam_r() 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/

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

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

Updated by naruse (Yui NARUSE) over 10 years 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.

Updated by akr (Akira Tanaka) over 10 years 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

Updated by djberg96 (Daniel Berger) over 10 years 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.

Updated by nobu (Nobuyoshi Nakada) over 10 years 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.
    [ruby-core:61325] [Bug #9600]

Updated by ReiOdaira (Rei Odaira) about 10 years ago

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

Updated by naruse (Yui NARUSE) about 10 years 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

Updated by nagachika (Tomoyuki Chikanaga) almost 10 years 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.

Updated by usa (Usaku NAKAMURA) almost 10 years 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0