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