Hello,
[email protected], le ven. 11 sept. 2026 11:38:25 +0200, a ecrit:
> Sep 10, 2026, 23:03 by [email protected]:
>
> > [email protected], le jeu. 10 sept. 2026 20:19:09 +0200, a ecrit:
> >
> >> Sep 10, 2026, 17:49 by [email protected]:
> >>
> >> > [email protected], le jeu. 10 sept. 2026 19:31:03 +0200, a ecrit:
> >> >
> >> >> Sep 10, 2026, 16:45 by [email protected]:
> >> >>
> >> >> >> 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 primary gid will be first in the list.to be processed by
> > idvec_merge_ids, and idvec_merge will leave the first element of
> > implied_gids as it is.
> >
> What if implied_gids is empty such as during login? I think this is what is
> causing my egid to be set to wheel (my first group) instead of my pw_gid
> after login.
That case would have to be handled specially by the software in charge
of the login process, indeed. But at least that's not many different
software to fix :)
> >> > 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?
> >
> > It can use getegid().
>
> You mean setgroups should prepend the current egid to the request to ensure
> Hurd conventions?
If it's not there yet, yes, e.g. running this as root:
#define _GNU_SOURCE
#include <grp.h>
#include <stdio.h>
#include <unistd.h>
int
main()
{
setegid(1);
gid_t foo[3] = {2,3};
setgroups(2, foo);
printf("%d\n", getegid());
int n = getgroups(3, foo);
printf("%d\n", n);
for (int i = 0; i < n; i++)
printf(" %d", foo[i]);
printf("\n");
}
currently prints
2
2
2 3
while it should really print either
1
2
2 3
or
1
3
1 2 3
It's the former on Linux but it's fine to have the latter on the Hurd.
Samuel
