Re: Position of primary group in in getgrouplist

[yelninei--- via Bug reports for the GNU Hurd]

Sep 10, 2026, 17:49 by samuel.thiba...@gnu.org:

> yelni...@tutamail.com, le jeu. 10 sept. 2026 19:31:03 +0200, a ecrit:
>
>> Sep 10, 2026, 16:45 by samuel.thiba...@gnu.org:
>>
>> >> Is this a bug in Hurd or in glibc/nscd? 
>> >> Changing the nscd lookup to insert the group name at the beginning 
>> >> instead of the end would fix it
>> >>
>> >
>> > Perhaps we just need to fix glibc's setgroups to make sure that the
>> > current effective gid is first in the list given to the auth server,
>> > fixing the order if needed.
>>
>> Fixing setgroups is not enough because i.e. _merge_implied_gids also assumes 
>> that the pw_gid is first for setgrouplist and does not use setgroups.
>>
>
> But doesn't it properly cope with keeping the first element first?
>
Yes it does. It is just that it gets the gid list from getgrouplist which might 
or might not have the pw_gid as the first element. Should that add the primary 
gid explicitly first and then merge the other gids afterwards?



> The only way that applications have to modify the list without knowing
> about the hurd convention is setgroups, as seen from a unix view.  So
> that's the only place that needs to take care of the conversion of
> convention, and everything below can just keep the hurd convention
> correct.
>
>> Wouldnt it be netter to ensure this in __nscd_getgrouplist to prepend the 
>> group instead of appending it and make the normal and nscd output identical?
>>
>
> That will only fix nscd. We want glibc to expose a unix behavior, so we
> have to fix it when it happens not to.
>
Once the list reaches setgroups there is no special gid anymore (apart from the 
hurd convention). How is setgroups supposed to know what the extra gid 
specified in the call to getgrouplist was and potentially "correct" the list?

>> There is a potential issue when the extra gid is already there because then 
>> it would contain duplicates and it needs to rewrite the list.
>>
>
> That is fine to rewrite the list. The manpage says it is unspecified
> whether the effective group ID is in the list.
>
>> That particular part of glibc has been unchanged since 2004 so this must 
>> have never worked?Y.
>>
>
> I would not really be surprised.
>
> Samuel
>