Subject: kern/4217: kernel's handling of group permissions is suboptimal
To: None <email@example.com>
From: None <cgd@NetBSD.ORG>
Date: 10/03/1997 23:00:13
>Synopsis: the kernel's handling of group permissions is suboptimal
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Fri Oct 3 16:05:05 1997
>Originator: Chris G. Demetriou
Kernel Hackers 'r' Us
>Release: NetBSD-current as of October 1, 1997
System: NetBSD brick.demetriou.com 1.2G NetBSD 1.2G (BRICK) #116: Wed Jul 16 14:03:06 PDT 1997 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/BRICK i386
The kernel's handling of group permissions is suboptimal. In
particular, it has (at least) the following deficiencies (for
(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
(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().
Try code which performs any of the above operations.
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!)