The good old "permission denied", the ignored group memberships, and a proposed solution

[Luc Pardon]

On Sat, 15 May 2021 19:23:10 +0300
Henrik K <hege at hege.li> wrote:

> On Sat, May 15, 2021 at 05:55:19PM +0200, Luc Pardon wrote:
> > 
> > Other than the extra dependency, I don't see any reason why not.  
> 
> Please never use horrible dependencies for trivial functions.
> Especially ones that are not readibly available for all
> distributions, or are just plain bloaty (the real dependency is the
> massive FFI::Platypus package).

If it can be done with less overhead and safely, I am all for it, of
course.

> 
> Just copy code from SpamAssassin for example, it's worked for a
> decade everywhere:

One would think that a decade would be plenty of time to get it copied
over into amavisd <g>.

Seriously, thanks for the pointer. It makes interesting reading for
somebody like me who is not a native Perl speaker.

> 
> https://metacpan.org/release/Mail-SpamAssassin/source/lib/Mail/SpamAssassin/Util.pm
> 
> Have a look at get_user_groups() and setuid_to_euid() which sets $) /
> $supgs.

The major problem that I have with assigning to $) is Perl bug RT
#134169 :

    https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134169

That can be dangerous, since $) may still retain group 0 and other
unwanted and unexpected things after the assigment.

Quoting from the bug report:

> perl 5.28 
> # perl -E 'say $); $)="104 104"; say $); say $! ' 
> 0 0 1 2 3 4 6 10 11 26 27
> 104 104 
> 
>
> perl 5.30 
> # perl -E 'say $); $)="104 104"; say $); say $! ' 
> 0 0 1 2 3 4 6 10 11 26 27
> 104 0 1 2 3 4 6 10 11 26 27 
> Invalid argument


The bug was introduced in Perl 5.30 and fixed in 5.31. Making that a
prerequisite may be a heaftier price than pulling in a Platypus by its
massive tail <g>.

Besides, it may be overkill to require Perl >= 5.31: Fedora
backported the patch in their 5.30.440 RPM (June 2019). Since the bug
was marked "critical", other distros may have done the same. 

But even with my patched 5.30 here, it still seems to go wrong if
$desired_user is a member of only one group. For example, with "apache"
(group 58), this is the initial value of $) when running as root on my
box :

    0 0 1 2 3 4 6 10

After the assignment (i.e. of the single "58") to $), it becomes:

    58 0 1 2 3 4 6 10    

OK, maybe I'm misunderstanding things here. And sure, it is
probably possible to work around it. Two assignments in a row seem to
work in both cases (single and multi-membership users), like this:

   $) = "$gid $gid";
   $) = $groups;

But it's still scary to me.

On my boxes, I think I'll stick with initgroups(), at least for now.

Maybe somebody could go ask the maintainers of the POSIX package to add
a call to the native function? Or maybe - dare I say it <g> - amavisd
could ship with a 5-line C program and compile that into a helper
binary to make the call on its behalf?