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
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:
> >
On Mon, Aug 19, 2019 at 5:08 AM Jan Braun 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
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 beha
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 exist
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=
