NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

misc/57073: max group name ill defined



	Note: There was a bad value `' for the field `Confidential'.
	It was set to the default value of `yes'.

>Number:         57073
>Category:       misc
>Synopsis:       max group name ill defined
>Confidential:   yes
>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
>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@localhost:/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.)

>Unformatted:
 	
 	



Home | Main Index | Thread Index | Old Index