getgroups returning a diferent result

[aleivag@xxxxxxxxx (aleivag)]

Thanks Michael, Jérémy

i found the code
https://github.com/systemd/systemd/blob/b0450864f1723ad12176d7956377d89ff4a84d8c/src/core/execute.c#L963
and you are right systemd explicitly dont load groups for root, and i guess
that is why getgroups return empty instead of failing. the good news (at
least for me :P ) is that i can execute initgroups myself on my program and
get all the groups for my user, and that also explain why i do have my
supplementary groups in my logged session (maybe logind or execute
initgroups for me).

thanks guys for your answers.

Alvaro Leiva Geisse


On Fri, Jun 15, 2018 at 1:57 AM Michael Chapman <mike at very.puzzling.org>
wrote:

> On Fri, 15 Jun 2018, Jérémy Rosen wrote:
> > Partial answer, I don't know all the details...
> >
> > We are all taught in school that each unix user belongs to to a certain
> number
> > of groups, and that is defined in /etc/passwd.
> >
> > That's kinda true, but it's an oversimplification.
> >
> > Each PROCESS has a user and a set of groups. Those groups are set when
> login
> > (or whoever does the login process) switch
> > from running as root to running as your user. At that point, it will
> > explicitely read /etc/passwd, set the correct groups then
> > switch to the final UID (which can't change groups anymore)
> >
> > This is the normal process when you login, but its a convention, not
> something
> > that is enforced by the kernel.
> >
> > IIUC systemd does not do that for services. Services only have a UID, a
> main
> > GID but no supplementary GIDs.
> >
> > Supplementary GID must be set explicitely with SupplementaryGroups= in
> > [Service] They won't be read from /etc/passwd
> >
> > That's my understanding, at least, someone else might know better...
>
> systemd does call initgroups(3) -- which populates a process's
> supplementary group list -- but only when the GID is _not_ 0. There's a
> comment in the code that it is to avoid an NSS lookup in this case, though
> I must admit I don't know the full rationale for it.
>
> It's probably got something to do with the fact that the group database
> in NSS won't necessarily be available early during boot, especially if
> it's backed onto some network
> service._______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180615/8d9f5beb/attachment.html>