Re: [systemd-devel] getgroups returning a diferent result

2018-06-15 Thread 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 
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] getgroups returning a diferent result

2018-06-15 Thread Michael Chapman 
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] getgroups returning a diferent result

2018-06-15 Thread Jérémy Rosen 

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...

HTH
Jérémy

On 15/06/2018 06:35, aleivag wrote:

hi systemd'ers , i'm sure this is known, but for the life of me i cant
seems to know why.

tldr; aparently i loose all auxiliary groups of root when i execute a unit.

i'll explain (i try this on v238).

when i'm logged in as root, and i execute `id` i get all the groups that
root belong to. but when i do the same in a systemd unit (e.g. under a
transien unit, a la systemd-run) i loose all groups. i suspect that this is
because the getgroups system call returns a different value, but for the
life of me, i don't know why or how. i'll show

on my normal bash

```
[homex ~]# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
```

i get all the groups, but if i run it with systemd-run

```
[homex ~]# systemd-run --pty id
Running as unit: run-u207.service
Press ^] three times within 1s to disconnect TTY.
uid=0(root) gid=0(root) groups=0(root)
```

the only group i see is root, now for the semi weird part, if i execute `id
root`, i do get all the groups

```
[homex ~]# systemd-run --pty id root
Running as unit: run-u220.service
Press ^] three times within 1s to disconnect TTY.
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
```

this is because getgroups return a diferent value if i'm in the unit or
logged in

```
[homex ~]# strace id 2>&1 | grep getgroups
getgroups(0, NULL)  = 8
getgroups(8, [0, 1, 2, 3, 4, 6, 10, 19]) = 8

[homex ~]# systemd-run --pty strace id 2>&1 | grep getgroups
getgroups(0, NULL)  = 0
getgroups(0, [])= 0
```

and the reson why i gett all the groups when i execute `id root`, is
because that does not ask for groups, but call libnss instead

```
[homex ~]# systemd-run --pty strace id root 2>&1 | grep getgroups
[homex ~]# systemd-run --pty strace id root 2>&1 | grep libnss
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/libnss_mymachines.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3
```

i guess i just wanna understand why this is, why this system call return
different values if i'm in bash or if i'm in a unit.

thanks guys!

Alvaro Leiva Geisse



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Devuan ASCII 2.0.0

2018-06-15 Thread freebsd 

Guten f morgen,

Just dropped by to announce that new version of malware(d) free Debian 
is available:


 https://devuan.org/os/debian-fork/ascii-stable-announce-060818

The tardfuck IAN murdock who let this plague happen to debian (used to 
be my favourite operating system) is let's just say:


"I'm not glad he's dead, but I'm glad he's gone"

Systemd and pulseaudio have to be shutdown for good, focus your time and 
energy on something more useful like inventing a 50% efficient solar 
panel or do cancer research instead of PRODUCING THIS FUCKING CANCER.


Systemd have to be discontined and removed from all the distributions so 
things can go back to normal as they used to be.


Anybody knows a good shitD free mediacenter by the way with KODI for 
Raspberry PI 2, 3?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel