Hi, 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 >> 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. Do you want the MACH_MSG_TYPE_COPY_SEND and signature change as separate patches? Do you want separate patches for seteuids and setgroups (the change and reason is basically identical) Is there something else I need to consider for patches to glibc? Thanks.Y. > Samuel >
