<div dir="ltr">Thanks Michael, <span style="color:rgb(32,33,36);font-size:14px;font-weight:bold;letter-spacing:0.2px;white-space:nowrap;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif">Jérémy</span><br><table cellpadding="0" class="gmail-cf gmail-gJ" style="border-collapse:collapse;margin-top:0px;width:auto;display:block;color:rgb(119,119,119);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;text-decoration-style:initial;text-decoration-color:initial"></table><div><br></div>i found the code <a href="https://github.com/systemd/systemd/blob/b0450864f1723ad12176d7956377d89ff4a84d8c/src/core/execute.c#L963">https://github.com/systemd/systemd/blob/b0450864f1723ad12176d7956377d89ff4a84d8c/src/core/execute.c#L963</a> 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).<div><br></div><div>thanks guys for your answers.<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><br>Alvaro Leiva Geisse<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 15, 2018 at 1:57 AM Michael Chapman <<a href="mailto:mike@very.puzzling.org">mike@very.puzzling.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 15 Jun 2018, Jérémy Rosen wrote:<br>
> Partial answer, I don't know all the details...<br>
> <br>
> We are all taught in school that each unix user belongs to to a certain number<br>
> of groups, and that is defined in /etc/passwd.<br>
> <br>
> That's kinda true, but it's an oversimplification.<br>
> <br>
> Each PROCESS has a user and a set of groups. Those groups are set when login<br>
> (or whoever does the login process) switch<br>
> from running as root to running as your user. At that point, it will<br>
> explicitely read /etc/passwd, set the correct groups then<br>
> switch to the final UID (which can't change groups anymore)<br>
> <br>
> This is the normal process when you login, but its a convention, not something<br>
> that is enforced by the kernel.<br>
> <br>
> IIUC systemd does not do that for services. Services only have a UID, a main<br>
> GID but no supplementary GIDs.<br>
> <br>
> Supplementary GID must be set explicitely with SupplementaryGroups= in<br>
> [Service] They won't be read from /etc/passwd<br>
> <br>
> That's my understanding, at least, someone else might know better...<br>
<br>
systemd does call initgroups(3) -- which populates a process's <br>
supplementary group list -- but only when the GID is _not_ 0. There's a <br>
comment in the code that it is to avoid an NSS lookup in this case, though <br>
I must admit I don't know the full rationale for it.<br>
<br>
It's probably got something to do with the fact that the group database <br>
in NSS won't necessarily be available early during boot, especially if <br>
it's backed onto some network service._______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div>