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:
(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.