Re: misc/57073: max group name ill defined

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR misc/57073; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: misc/57073: max group name ill defined
Date: Wed, 26 Oct 2022 07:25:15 +0000

 On Mon, Oct 24, 2022 at 02:00:00PM +0000, jschauma%netmeister.org@localhost wrote:
  > Define a max group name length and don't let groupadd or other
  > functions etc. go beyond that.
  > 
  > I don't know what the best value for the max should be, but perhaps setting
  > it to LOGIN_NAME_MAX would make sense, as often groups are created using
  > usernames as the group name.
 
 While this is a good step to take, it's not sufficient. The reason
 there's no specific limit on the name is that in some sense the
 important limit is the maximum length of a line in /etc/group (or
 other data sources for it) and that includes the names of the group
 members.
 
 The internal limit on this appears to be _GETGR_R_SIZE_MAX in
 limits.h, which is 1024 and mentions "IEEE Std 1003.1-2001 TSF".
 
 user.c has its own definition MaxEntryLen = 2048; I'm not sure how to
 square that with the 1024 limit inside getgrent.c, but user.c seems to
 mix getgrent/getgrnam/etc. calls with direct accesses to /etc/group;
 probably that means it can create entries that are longer than
 getgrent.c can read, which is not optimal.
 
 (Also it looks like user.c will probably corrupt /etc/groups if it
 hits a line that's longer than 2048. Sigh.)
 
 (note: user.c is in src/usr.sbin/user and implements both the group
 and user ops of useradd/groupadd/etc.)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost