[Bug 220779] getgroups result is affected by setegid

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220779

Konstantin Belousov <kib at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brooks at FreeBSD.org,
                   |                            |kib at FreeBSD.org

--- Comment #3 from Konstantin Belousov <kib at 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 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.