NetBSD Problem Report #4217

Received: (qmail 20905 invoked by uid 1000); 3 Oct 1997 23:00:13 -0000
Message-Id: <19971003230013.20904.qmail@mail.NetBSD.ORG>
Date: 3 Oct 1997 23:00:13 -0000
From: cgd@netbsd.org
Reply-To: cgd@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: kernel's handling of group permissions is suboptimal
X-Send-Pr-Version: 3.95

>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
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 03 16:05:05 +0000 1997
>Closed-Date:    
>Last-Modified:  Sun Aug 10 16:26:01 +0000 2003
>Originator:     Chris G. Demetriou
>Release:        NetBSD-current as of October 1, 1997
>Organization:
Kernel Hackers 'r' Us
>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!)
>Release-Note:
>Audit-Trail:

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@gnats.netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: re: kern/4217: the kernel's handling of group permissions is suboptimal
Date: Sun, 10 Aug 2003 09:37:14 +0100

 1) Posix takes the stance:
     The related function setgroups() is a privileged operation and
     therefore is not covered by this volume of IEEE Std 1003.1-2001.
    which is rather a copout and not helpful at all!

 2/3/4) Posix requires the current behaviour.
    Although I agree that being able to call setgid() with any of the
    supplemantary groups could be useful - although of limited use
    given that netbsd doesn't use the actual group for very much.

 Perhaps the documentation of setgroups should be changed?
 Or maybe we should let a non-priveleged user re-order the list?

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Andrew Brown <atatat@atatdot.net>
To: David Laight <david@l8s.co.uk>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/4217: the kernel's handling of group permissions is suboptimal
Date: Sun, 10 Aug 2003 12:25:35 -0400

 >1) Posix takes the stance:
 >    The related function setgroups() is a privileged operation and
 >    therefore is not covered by this volume of IEEE Std 1003.1-2001.
 >   which is rather a copout and not helpful at all!

 if the man page says "only the superuser can add more groups" and
 posix says "hey, look...a yak", then it doesn't seem to me to be wrong
 to adjust the code slightly in order to allow people to lower their
 privileges.

 >2/3/4) Posix requires the current behaviour.
 >   Although I agree that being able to call setgid() with any of the
 >   supplemantary groups could be useful - although of limited use
 >   given that netbsd doesn't use the actual group for very much.

 uh...nfs?  besides, it would be rather useful if a process that had
 gained privileges via a setgid binary to be able to give away all its
 other group privileges...

 >Perhaps the documentation of setgroups should be changed?

 nah...

 >Or maybe we should let a non-priveleged user re-order the list?

 yeah...

 imho.

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."
>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.