Hello, [email protected], le mer. 30 sept. 2026 17:00:11 +0200, a ecrit: > Sep 29, 2026, 20:51 by [email protected]: > > >> >> Is setgroups the only libc function that has the problem? > >> > > >> > Mmmm. On GNU/Hurd only we define the equivalent seteuids for uids, I > >> > would say that we would want to have the same behavior, that will be > >> > less surprising to programmers. > >> > >> Does seteuids have the same semantic to only change "supplementary uids"? > >> The comment says it sets uids for the "current user" so I would assume it > >> also does not change the current euid. > >> > > > > That's what I meant, yes. codesearch.debian.net doesn't show any user of > > seteuids, so we can fix that semantic to match setgroups' > > > >> There is also a slight inconsistency that for setgroups the amount is > >> size_t while for geteuids it is int. > >> > > > > Indeed. I would say to just fix it. > > > I guess posix is also not sure what it should be because getgroups has int > for the array size. > So either way there is a mismatch between getter and setter or uids/guids
Actually, strictly speaking posix doesn't define setgroups (because it is a privileged operation there) So both setgroups and seteuids are extensions, better keep them coherent :) > >> I tried to use just like setgroups and it always fails with > >> EMIG_BAD_ARGUMENTS. Am I doing something wrong? > >> > > > > I find it surprising that the __auth_makeauth call doesn't have > > MACH_MSG_TYPE_COPY_SEND like setgroups does. It was probably never > > actually tested. > > > > Using MACH_MSG_TYPE_COPY_SEND seems to fix it and it works like the current > setgroups. > Changing seteuids with a similar patch like setgroups it then it then ensures > to leave the current euid unchanged. Good :) > Do you want the MACH_MSG_TYPE_COPY_SEND and signature change as separate > patches? Yes, please. > Do you want separate patches for seteuids and setgroups (the change and > reason is basically identical) Better keep them together in one patch. > Is there something else I need to consider for patches to glibc? Nothing really particular. Since it's completely specific to the Hurd port, we don't have constraints. Thanks, Samuel
