From owner-freebsd-standards@freebsd.org Mon Jul 17 07:41:51 2017 Return-Path: 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 B4CD6CFECD4; Mon, 17 Jul 2017 07:41:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 5318E76DCE; Mon, 17 Jul 2017 07:41:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id F255DD4326E; Mon, 17 Jul 2017 17:24:20 +1000 (AEST) Date: Mon, 17 Jul 2017 17:24:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: freebsd-bugs@freebsd.org cc: freebsd-standards@freebsd.org Subject: Re: [Bug 220779] getgroups result is affected by setegid In-Reply-To: Message-ID: <20170717164107.G987@besplex.bde.org> References: MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=H0_7l9-vTDGpUrcDqUwA:9 a=KFWnM6puAmAvoMnU:21 a=KWWYgJPqlzTOqg8r:21 a=45ClL6m2LaAA:10 a=IjZwj45LgO3ly-622nXo:22 a=6kGIvZw6iX1k4Y-7sg4_:22 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:41:51 -0000 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: 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 ; 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 ; 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 ; 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #3 from Jilles Tjoelker --- 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.=