Subject: kern/4217: kernel's handling of group permissions is suboptimal
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@NetBSD.ORG>
List: netbsd-bugs
Date: 10/03/1997 23:00:13
>Number:         4217
>Category:       kern
>Synopsis:       the kernel's handling of group permissions is suboptimal
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Oct  3 16:05:05 1997
>Last-Modified:
>Originator:     Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release:        NetBSD-current as of October 1, 1997
>Environment:
System: NetBSD brick.demetriou.com 1.2G NetBSD 1.2G (BRICK) #116: Wed Jul 16 14:03:06 PDT 1997 cgd@brick.demetriou.com:/usr/src/sys/arch/i386/compile/BRICK i386


>Description:
	The kernel's handling of group permissions is suboptimal.  In
	particular, it has (at least) the following deficiencies (for
	non-superusers):

	(1) setgroups() can only be invoked by root, despite the fact
	    that the manual page says that "only the super-user may set
	    new groups."  It's impossible for a process to _remove_
	    groups from its group access list.  This means that it's
	    impossible for a "smart" process to completely relinquish
	    certain privileges.

	(2) setgid() can't set group ID to one of the groups in the
	    group access list, only to either the real group id or the
	    saved group id.  This, too, means that it's impossible
	    for a "smart" process to relinquish certain privileges.  Such
	    a process might want to setgid() to a certain group ID, then
	    relinquish other group membership, then invoke another program.

	(3) same as (2), but for setegid().

	(3) same as (2), but for setregid().

>How-To-Repeat:
	Try code which performs any of the above operations.

>Fix:
	None provided.  Note that there are 'interesting' issues if
	the real or effective group IDs aren't in the process's
	group list; logically they probably should be.  (That doesn't
	necessarily have to be reported directly to user programs which
	do getgroups(), but having one array could make life a lot easier.
	Indeed, it might make life easier in the existing code!)
>Audit-Trail:
>Unformatted: