NetBSD Problem Report #57073

From jschauma@netmeister.org  Mon Oct 24 13:56:21 2022
Return-Path: <jschauma@netmeister.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 08C231A921F
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 24 Oct 2022 13:56:21 +0000 (UTC)
Message-Id: <20221024135616.4143085851@panix.netmeister.org>
Date: Mon, 24 Oct 2022 09:56:16 -0400 (EDT)
From: jschauma@netmeister.org
Reply-To: jschauma@netmeister.org
To: gnats-bugs@NetBSD.org
Subject: max group name ill defined
X-Send-Pr-Version: 3.95

>Number:         57073
>Category:       misc
>Synopsis:       max group name ill defined
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 24 14:00:00 +0000 2022
>Last-Modified:  Wed Oct 26 07:30:02 +0000 2022
>Originator:     Jan Schaumann
>Release:        NetBSD 9.3
>Organization:

>Environment:


System: NetBSD panix.netmeister.org 9.3 NetBSD 9.3 (PANIX-VC) #0: Tue Aug 9 17:50:54 EDT 2022 root@juggler.panix.com:/misc/obj64/misc/devel/netbsd/9.3/src/sys/arch/amd64/compile/PANIX-VC amd64
Architecture: x86_64
Machine: amd64
>Description:

It looks like we do not have a maximum length set for group names along the
lines of LOGIN_NAME_MAX for usernames.  This leads to bizarre and flawed outcomes
when e.g., trying to add groups with long names.

For example:
---
#! /bin/sh

previous=$(tail -1 /etc/group | awk -F: '{print $3}')

for n in 998 999 1000; do
	g=$(yes x | head -${n} | tr -d '\n')
	groupadd "${g}"
	if [ $? -gt 0 ]; then
		echo "Unable to add a group with ${n} chars." >&2;
		exit 1;
	fi
	gid=$(group info "${g}" | awk '/^gid/ { print $2}')
	if [ x"${gid}" = x"" ]; then
		echo "Unable to get group info for group I just added." >&2
		gid=$(tail -1 /etc/group | awk -F: '{print $3}')
	fi
	if [ x"${previous}" = x"${gid}" ]; then
		echo "Group with ${n} chars has same gid as previous group." >&2
	fi
	previous="${gid}"
done
---

The result here is that the first group with 998 characters is created with
(in my case) GID 1000.  "group info" succeeds, all's peachy.

groupadd with a 999 character name succeeds, creating a group with GID 1001,
but "group info" for the same group fails.

groupadd with a 1000 character name succeeds, but creates a group with
GID 1001, presumably because just like for "group info", getgrnam(2)
checking for the existence of the group failed.


>How-To-Repeat:

Run the above script.

>Fix:

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.

(Different other Unix versions seem to have different maximum values for
historical reasons.)

>Release-Note:

>Audit-Trail:

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
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 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

>Unformatted:

Home	PR Database Search