Date: Mon, 17 Jul 2017 17:24:19 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: freebsd-bugs@freebsd.org Cc: freebsd-standards@freebsd.org Subject: Re: [Bug 220779] getgroups result is affected by setegid Message-ID: <20170717164107.G987@besplex.bde.org> In-Reply-To: <bug-220779-15@https.bugs.freebsd.org/bugzilla/> References: <bug-220779-15@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Jul 2017 a bug that doesn't want replies@freebsd.org wrote:
> ...
> Summary: getgroups result is affected by setegid
> ...
> Reporter: muh.muhten@gmail.com
>
> On FreeBSD, the groups applicable to a process are stored in an array wit=
h the
> egid in [0] and and zero or more (not necessarily distinct) additional gi=
ds in
> sorted order.
>
> The setgid, setegid, and setregid functions change the egid of a process,=
but
> the process's supplementary group ids are to remain unchanged. Since getg=
roups,
> which claims to conform to IEEE Std 1003.1-2008 (=E2=80=9CPOSIX.1=E2=80=
=9D), is defined to fill
> its second argument with calling process's supplementary group ids, so it=
s
No, its second arg is filled with the egid and then the supplementary group
ids.
> output must not include the egid, which is changed by setgid &c.. The cur=
rent
> implementation fills the second argument with the entire groups array, wh=
ich
> does include the egid in [0].
Slot [0] is the non-supplementary part of the list.
> - "The setgid() function shall not affect the supplementary group list in=
any
> way. Any supplementary group IDs of the calling process shall remain
> unchanged."
> - "The setegid() function shall not affect the supplementary group list i=
n any
> way."
> - (ditto for setregid)
Satisified since setting the gid only changes slot [0] in the list.
> - "The getgroups() function shall fill in the array grouplist with the cu=
rrent
> supplementary group IDs of the calling process. It is implementation-defi=
ned
> whether getgroups() also returns the effective group ID in the grouplist
> array."
This is what allows FreeBSD to return the gid in slot [0].
> - "A process has up to {NGROUPS_MAX} supplementary group IDs in addition =
to the
> effective group ID."
So in implementations that return the egid in the array, the array can have
length 1 + {NGROUPS_MAX} elements. POSIX says this too.
FreeBSD used to have an off-by-1 bug in this area. It used to have a limit
of {NGROUPS_MAX} elements in the array. So it didn't actually support
{NGROUPS_MAX} supplementary gids, but 1 less than that. When I looked at
that many years ago, I suspected that it had the bug in this PR, but I
can't see this bug now.
There are still bugs in this area:
- FreeBSD doesn't document its implementation-defined behaviour that
getgroups() returns the egid in the array. It's getgroups(2) man
page doesn't use the POSIX term "supplementary group" at all, but uses
the generic term "group list".
- POSIX doesn't require getgroups() to return the egid in any particular
place in the array (or disallow returning it more than once if there is
space to spare). So it is not a bug for FreeBSD to not document the
particular place that it uses, but applications have a difficult time
determining which ids in the list are supplementary.
- POSIX is not completely clear about disallowing multiple filling of the
list with supplementary ids when there is space to spare, or about wasti=
ng
space so that there is not enough. The 2001 version even seems to allow
expanding the return value beyond 1 + {NGROUPS_MAX} in the case where
the egid is not returned, to provide enough space after wasting some.
Bruce
From owner-freebsd-standards@freebsd.org Mon Jul 17 22:09:55 2017
Return-Path: <owner-freebsd-standards@freebsd.org>
Delivered-To: freebsd-standards@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03245DA25BB
for <freebsd-standards@mailman.ysv.freebsd.org>;
Mon, 17 Jul 2017 22:09:55 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id E524C74983
for <freebsd-standards@FreeBSD.org>; Mon, 17 Jul 2017 22:09:54 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6HM9sXN070218
for <freebsd-standards@FreeBSD.org>; Mon, 17 Jul 2017 22:09:54 GMT
(envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-standards@FreeBSD.org
Subject: [Bug 220587] /bin/sh Incorrect options handling
Date: Mon, 17 Jul 2017 22:09:55 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 11.0-RELEASE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: jilles@FreeBSD.org
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-220587-15-zPgN1321na@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-220587-15@https.bugs.freebsd.org/bugzilla/>
References: <bug-220587-15@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-standards@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Standards compliance <freebsd-standards.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-standards>,
<mailto:freebsd-standards-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-standards/>;
List-Post: <mailto:freebsd-standards@freebsd.org>
List-Help: <mailto:freebsd-standards-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-standards>,
<mailto:freebsd-standards-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 22:09:55 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220587
Jilles Tjoelker <jilles@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
--- Comment #3 from Jilles Tjoelker <jilles@FreeBSD.org> ---
You are right that FreeBSD sh deviates here, but I do not agree with your
patch. POSIX specifies that -c's command_string is an operand and not an
option-argument (but -o does take an option-argument). Therefore in
sh -ca 'echo $-:$0'
and
sh -c -a 'echo $-:$0'
the allexport option should be set, while in
sh -c 'echo $-:$0' -a
the allexport option should not be set and $0 should be set to "-a".
Your patch fixes the latter case at the cost of breaking the former case, w=
hile
the middle case remains broken.
Various shells such as bash, ksh93 and mksh handle all three cases correctl=
y.
Note that this means that passing a command string starting with "-" to pop=
en()
or system() shall not execute that string as a command, since sh will inter=
pret
it as containing options and there will not be a command_string for -c.
A command string starting with "-" can be passed like
sh -c -- '-a; echo continued'
which bash, ksh93 and mksh also support and we do not. The specification for
popen() and system() is unambiguous about the command that should be used,
though, and it does not include "--".
Please forget about the NOHACK code. Apart from the fact that this kind of
thing makes a poor compile-time option, the NOHACK case has been obviously
broken since it was added, because it uses q uninitialized if (*p !=3D '\0'=
). I
will take it out soon.
The easiest way to run the test suite is to install everything and then run=
as
root
cd /usr/tests/bin/sh && kyua test
If these directories do not exist, place WITH_TESTS=3DYES in /etc/src.conf,
rebuild and reinstall.
An uninstalled sh can be tested against installed tests by running
cd /usr/tests/bin/sh && kyua -v
test_suites.FreeBSD.bin.sh.test_shell=3D/path/to/test/sh test
This latter command might break in the future since this feature should be
provided generically, not specifically to sh.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170717164107.G987>