Fails with large groups

[jethrogb]

Describe the bug
When a group has a lot of members, sudo-rs doesn't work properly.

When sudo-rs tries to determine the gid of a named group, it calls getgrnam_r. It supplies a buffer of sysconf(_SC_GETGR_R_SIZE_MAX) or 16384 bytes. If that buffer is too small, getgrnam_r fails with ERANGE, and sudo-rs assumes the named group doesn't exist.

Expected behavior
sudo-rs should properly resolve group names for evaluating authorizations. Note that groups can have hundreds of thousands of members in large organizations.

Here's what the Linux man page for getgrnam_r states in relevant part:

The call

         sysconf(_SC_GETGR_R_SIZE_MAX)

returns either -1, without changing errno, or an initial suggested size for buf. (If this size is too small, the call fails with ERANGE, in which case the caller can retry with a larger buffer.)

If getgrnam_r returns ERANGE, sudo-rs should retry with increasingly large buffer sizes.

Environment (please complete the following information):
On my system, _SC_GETGR_R_SIZE_MAX is 1024 but I have a group entry of 1182 bytes.

[bjorn3]

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrnam.html seems to imply that this sysconf needs to either return a hard upper limit or return -1 if there is no upper limit, so this would be a violation of the POSIX standard. That said we will need to support glibc even if it violates the POSIX standard, so we will need to implement growing the buffer. https://bugs.ruby-lang.org/issues/9600#note-4 suggests that different OSes return different error codes when the buffer is too small.

[jethrogb]

Even the Open Group documentation has the “initial value suggested for the size of this buffer” language.

[squell]

Just venting a bit of frustation: this is a pretty annoying issue since we don't actually use getgrnam_r or getgrgid_r for the actual group lookups. I agree with Bjorn that the documentation of this function is poor (e.g. the OpenBSD version does really claim that sysconf() describes the upper limit). But it wouldn't be the only place we work around issues.

(But, working on a fix)

[squell]

Note that while I'm working on a dynamic resizing function for getgrnam_r/getgrgid_r, there's still the possibility that the buffer needed to call getgrnam_r is too large for our tastes; I see three options here:

• No imposed upper limit. The slight risk here is that if a system is compromised somehow (either intentionally or by accident) this could lead sudo to allocate/fill all the available memory. In most places in sudo-rs we impose constrains on things in line with a certain safety mindset.

• panic! if the limit is reached (downside: sudo simply doesn't work), or even turn it into a normal user error.

• Fail softly in retrieving the group (as is the current behaviour)

A reasonable upper limit could be something like u32::MAX.