Date: Wed, 04 Oct 2017 06:54:26 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 220779] getgroups result is affected by setegid Message-ID: <bug-220779-15-33MDNxlLZ9@https.bugs.freebsd.org/bugzilla/> 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220779 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brooks@FreeBSD.org, | |kib@FreeBSD.org --- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> --- The SUSv4TC2 is quite explicit about it. It allows either behavior, even accepting changing behavior on the same system: As implied by the definition of supplementary groups, the effective group ID may appear in the array returned by getgroups() or it may be returned only by getegid( ). Duplication may exist, but the application needs to call getegid( ) to be sure of getting all of the information. Various implementation variations and administrative sequences cause the set of groups appearing in the result of getgroups( ) to vary in order and as to whether the effective group ID is included, even when the set of groups is the same (in the mathematical sense of ``set''). (The history of a process and its parents could affect the details of the result.) So as far as no group ids are dropped by an operation, it is fine to have egid to not appear in the secondary group list, or to appear after further changes. Can you demonstrate a case where we loose a group from the list ? --=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?bug-220779-15-33MDNxlLZ9>