chpst -u and supplementary groups

chpst -u and supplementary groups

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Hello list!

Yesterday, I spent way too much time chasing down a permissions problem
caused by the fact that "chpst -u acc prog..." only sets the account's
primary group, and ignores any supplementary groups the account may be a
member of.

TFM mentions "All initial supplementary groups are removed.", but I
failed to memorize that. (Also, what does "initial" signify here?)

My inability to see the issue came from the fact that all other similar
programs (I'm aware of) do in fact add the supplementary groups. Watch:

| # chpst -u test id
| uid=1003(test) gid=1003(test) groups=1003(test)
| # runuser -u test id
| uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
| # s6-setuidgid test id
| uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
| # su - test -c id
| uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
| # su test -c id
| uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
| # sudo -u test id
| uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
| #

So now I'm wondering:
What are the use cases for not applying existing supplementary groups?
Should chpst apply them by default?
Should chpst grow an option to (not) apply them?
    "chpst -u acc: prog..." is still free.
Or is everything as it's supposed to be, and people might need to munge
    the output of "getent initgroups acc" and feed it to the -u option?

I'll be happy to try to come up with a patch (even if it's still a
fatter warning in the manpage) if people can agree here what the right
thing to do is.

regards,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: chpst -u and supplementary groups

[Steve Litt]

On Mon, 19 Aug 2019 14:08:07 +0200
Jan Braun <janbraun@gmx.de> wrote:

> Hello list!
> 
> Yesterday, I spent way too much time chasing down a permissions
> problem caused by the fact that "chpst -u acc prog..." only sets the
> account's primary group, and ignores any supplementary groups the
> account may be a member of.
> 
> TFM mentions "All initial supplementary groups are removed.", but I
> failed to memorize that. (Also, what does "initial" signify here?)
> 
> My inability to see the issue came from the fact that all other
> similar programs (I'm aware of) do in fact add the supplementary
> groups. Watch:
> 
> | # chpst -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test)
> | # runuser -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # s6-setuidgid test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su - test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # sudo -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | #
> 
> So now I'm wondering:
> What are the use cases for not applying existing supplementary groups?
> Should chpst apply them by default?
> Should chpst grow an option to (not) apply them?
>     "chpst -u acc: prog..." is still free.
> Or is everything as it's supposed to be, and people might need to
> munge the output of "getent initgroups acc" and feed it to the -u
> option?
> 
> I'll be happy to try to come up with a patch (even if it's still a
> fatter warning in the manpage) if people can agree here what the right
> thing to do is.
> 
> regards,
>     Jan

Thanks Jan,

I was having a similar problem,  and inspired by your post, I solved it
the following way, using Runit's chpst:

chpst  -u slitt:audio:disk   /tmp/test.sh

In the preceding, /tmp/test.sh was permissioned 750 owner root.audio,
and contained the following:

#!/bin/sh
whoami
cat /d/audio.group
cat /d/disk.group
groups
pwd

file /d/audio.group was 640 root.audio, while /d/disk.group was 640
root.disk. Both cat statements printed out the contents of the files,
proving that I was acting with both groups disk and audio. The output
of the whoami proved I was acting as user slitt.

You're obviously right that having all the groups slitt belongs to,
which include both disk and audio, would have been easier, but as you
say, it doesn't work right now, so I used this method for the time
being.

Thanks for helping me solve my problem.

SteveT

Steve Litt 
August 2019 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28

Re: chpst -u and supplementary groups

[Bougy Man]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

When I need this functionality, I generally use `groups=id -G|sed -e
's/\s/:/g'` then `chpst -u myuser:$groups` for the command line. This is
almost always just for processes I want to run as my own user, so it's a
rarity.

Tj

On Mon, Aug 19, 2019 at 7:08 AM Jan Braun <janbraun@gmx.de> wrote:

> Hello list!
>
> Yesterday, I spent way too much time chasing down a permissions problem
> caused by the fact that "chpst -u acc prog..." only sets the account's
> primary group, and ignores any supplementary groups the account may be a
> member of.
>
> TFM mentions "All initial supplementary groups are removed.", but I
> failed to memorize that. (Also, what does "initial" signify here?)
>
> My inability to see the issue came from the fact that all other similar
> programs (I'm aware of) do in fact add the supplementary groups. Watch:
>
> | # chpst -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test)
> | # runuser -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # s6-setuidgid test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su - test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # sudo -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | #
>
> So now I'm wondering:
> What are the use cases for not applying existing supplementary groups?
> Should chpst apply them by default?
> Should chpst grow an option to (not) apply them?
>     "chpst -u acc: prog..." is still free.
> Or is everything as it's supposed to be, and people might need to munge
>     the output of "getent initgroups acc" and feed it to the -u option?
>
> I'll be happy to try to come up with a patch (even if it's still a
> fatter warning in the manpage) if people can agree here what the right
> thing to do is.
>
> regards,
>     Jan
>

Re: chpst -u and supplementary groups

[Jonathan de Boyne Pollard]

> My inability to see the issue came from the fact that all other 
> similar programs (I'm aware of) do in fact add the supplementary groups.
>
Then you are not aware of Bernstein daemontools, where setuidgid does 
not.  (-:

# /package/admin/djbwares/command/setuidgid operator id
uid=2(operator) gid=5(operator) groups=5(operator)
#

* http://jdebp.uk./Softwares/djbwares/guide/commands/setuidgid.xml

Setting only one group was the behaviour of the original tool. Setting 
the supplementary groups as well is behaviour that others added to their 
toolsets later.  Bruce Guenter (in daemontools-encore) and I added it as 
an optional behaviour for setuidgid.

# /package/admin/nosh/command/setuidgid operator id
uid=2(operator) gid=5(operator) groups=5(operator)
# /package/admin/nosh/command/setuidgid --supplementary operator id
uid=2(operator) gid=5(operator) groups=5(operator),1298(log)
#

* http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid.xml

* http://untroubled.org/daemontools-encore/setuidgid.8.html

Re: chpst -u and supplementary groups

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Jonathan de Boyne Pollard schrob:
> > My inability to see the issue came from the fact that all other similar
> > programs (I'm aware of) do in fact add the supplementary groups.
> > 
> Then you are not aware of Bernstein daemontools, where setuidgid does not.
> (-:

Well, I am aware of their existance, but I've never used them, only
various descendants. I even suspected they might not handle
supplementary groups, because e.g. s6-envuidgid introduces GIDLIST to
deal with them.

> Setting only one group was the behaviour of the original tool. Setting the
> supplementary groups as well is behaviour that others added to their
> toolsets later.  Bruce Guenter (in daemontools-encore) and I added it as an
> optional behaviour for setuidgid.

Yes. Apparently everyone re-implementing daemontools does something like
this. So that brings me back to my original question: is there consensus
that the historical behaviour is a bug? Or are there valid use cases¹?

cheers,
    Jan

¹) Besides when the account has no supplementary groups, obviously.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: chpst -u and supplementary groups

[Laurent Bercot]

>Yes. Apparently everyone re-implementing daemontools does something like
>this. So that brings me back to my original question: is there consensus
>that the historical behaviour is a bug? Or are there valid use cases¹?

  I don't think the historical behaviour is a *bug*, because the
historical behaviour is documented and conforms to its documentation.
It also comes from a time when supplementary groups weren't used as
much as they are today.

  It's just that not having supplementary groups can defeat intuitive
expectations when performing a group permissions check. That does not
happen every day, but it does happen sometimes. s6-setuidgid had the
same behaviour as setuidgid until I got bitten by that very problem,
at which point I realized that "user identity" is not only uid and gid
as it is for files, but also supplementary groups, and so I added
supplementary groups support to s6-*uidgid. But it had been years
until I found it necessary.

  So, YMMV. I'd say supplementary groups support is useful and allows
the tool to better match user intuition, so it has value. But is it
*mandatory* for correctness? You decide.

--
  Laurent

Re: chpst -u and supplementary groups

[Cameron Nemo]

On Mon, Aug 19, 2019 at 5:08 AM Jan Braun <janbraun@gmx.de> wrote:
>
> Hello list!
>
> Yesterday, I spent way too much time chasing down a permissions problem
> caused by the fact that "chpst -u acc prog..." only sets the account's
> primary group, and ignores any supplementary groups the account may be a
> member of.
>
> TFM mentions "All initial supplementary groups are removed.", but I
> failed to memorize that. (Also, what does "initial" signify here?)
>
> My inability to see the issue came from the fact that all other similar
> programs (I'm aware of) do in fact add the supplementary groups. Watch:
>
> | # chpst -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test)
> | # runuser -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # s6-setuidgid test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su - test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # su test -c id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | # sudo -u test id
> | uid=1003(test) gid=1003(test) groups=1003(test),4(adm)
> | #

Most of these (su, sudo, runuser) go through PAM.
su and sudo are primarily targeted at interactive use.
I found another outlier, Google's minijail0:

/ # chpst -u cameronnemo /usr/bin/id
uid=1000(cameronnemo) gid=1000(cameronnemo) grupos=1000(cameronnemo)
/ # minijail0 -u cameronnemo /usr/bin/id
uid=1000(cameronnemo) gid=0(root) grupos=0(root)
/ # minijail0 -u cameronnemo -g cameronnemo /usr/bin/id
uid=1000(cameronnemo) gid=1000(cameronnemo) grupos=1000(cameronnemo)

>
> So now I'm wondering:
> What are the use cases for not applying existing supplementary groups?
It requires additional fact finding by what amounts to a shim between
the OS and the service.
Use cases are questionable -- why is a login session not more suitable?
Workarounds and other options exist, as demonstrated above.
> Should chpst apply them by default?
I would rather it not.
> Should chpst grow an option to (not) apply them?
Depends on the implementation.
>     "chpst -u acc: prog..." is still free.
> Or is everything as it's supposed to be, and people might need to munge
>     the output of "getent initgroups acc" and feed it to the -u option?
Yeah let's not do this. A good implementation is possible, and has been done.

> I'll be happy to try to come up with a patch (even if it's still a
> fatter warning in the manpage) if people can agree here what the right
> thing to do is.

Nobody maintains runit, so who is taking this patch?

> regards,
>     Jan

Cheers,
Cameron

Re: chpst -u and supplementary groups

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Cameron Nemo schrob:
> Most of these (su, sudo, runuser) go through PAM.
> su and sudo are primarily targeted at interactive use.

As a shell junkie, I don't subscribe to the viewpoint that there's a
measurable difference between "interactive use" and "scripting". ;)

> > So now I'm wondering:
> > What are the use cases for not applying existing supplementary groups?
> It requires additional fact finding by what amounts to a shim between
> the OS and the service.

That's not a use case, that's just the KISS ssoftware design principle.
But are there actually reasons for wanting to *avoid* a user's
supplementary groups, implementation issues aside?

> Use cases are questionable -- why is a login session not more suitable?

I'm sorry, I don't understand. What's a login session?

> Yeah let's not do this. A good implementation is possible, and has been done.
> 
> [...]
> 
> Nobody maintains runit, so who is taking this patch?

Dmitry Bogatov has been quite active in runit integration for Debian
during the last year or so.

This is what vexes me about the daemontools family. Apparently it's so
easy to reimplement them that people keep doing that. Instead of working
together to get one implementation polished enough to make a big unix
distro use it by default.

cheers,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: chpst -u and supplementary groups

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

Laurent Bercot schrob:
>  I don't think the historical behaviour is a *bug*, because the
> historical behaviour is documented and conforms to its documentation.

Well, let's say "misfeature" ;)

> It also comes from a time when supplementary groups weren't used as
> much as they are today.
> 
>  It's just that not having supplementary groups can defeat intuitive
> expectations when performing a group permissions check. That does not
> happen every day, but it does happen sometimes. s6-setuidgid had the
> same behaviour as setuidgid until I got bitten by that very problem,
> at which point I realized that "user identity" is not only uid and gid
> as it is for files, but also supplementary groups, and so I added
> supplementary groups support to s6-*uidgid. But it had been years
> until I found it necessary.

Ok, that's the kind of answer I was hoping for, thanks.

>  So, YMMV. I'd say supplementary groups support is useful and allows
> the tool to better match user intuition, so it has value. But is it
> *mandatory* for correctness? You decide.

I don't need to decide that. :) I already knew that *I* needed
supplementary group support. The only question was whether I should
implement it in runit's source code, or by piping the output of getent
through sed, and writing "chpst -u `userid acc` prog..." in my
runscripts as a matter of habit. And now the former sounds like the more
reasonable course of action. I'll go have a look at the code...

cheers,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: chpst -u and supplementary groups

[Steve Litt]

On Wed, 21 Aug 2019 05:22:10 +0200
Jan Braun <janbraun@gmx.de> wrote:


> This is what vexes me about the daemontools family. Apparently it's so
> easy to reimplement them that people keep doing that. Instead of
> working together to get one implementation polished enough to make a
> big unix distro use it by default.
> 
> cheers,
>     Jan

Far as I'm concerned, they're *all* polished enough to make a big unix
distro use it by default. The problem is politics and money.

In other words, the best of them all could be rolled into one software,
and it still wouldn't be accepted, because Red Hat has many millions
for marketing and halloween code to prevent that.

The reason daemontools-inspired init/supervisors weren't used before
systemd was because nobody was dissatisfied with sysvinit and/or
upstart, so nobody even knew about the others. 

SteveT

Steve Litt 
August 2019 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28

Re: chpst -u and supplementary groups

[Jeff]

> Apparently everyone re-implementing daemontools does something like
> this. So that brings me back to my original question:
> is there consensus that the historical behaviour is a bug?

no, this is no bug.

> Or are there valid use cases?

most of the time one does not want the subprocess to run under
additional GIDs, so that is a sane default behaviour.

obviously there should be an option that makes "chpst" add all
supplementary GIDs the UID belongs to, though
(when this is desired by the user).

would not be too much work to add such a commandline option to it.