Bug 1095670

As described it is specific to bash which explicitly resets list of supplementary groups in disable_priv_mode () (patch bash-4.4.dif). So forwarding to bash maintainer ...

POS36-C: "Consequently, it is recommended that a program relinquish supplementary group IDs immediately before relinquishing root privileges."
rpmlint warns about a missing-call-to-setgroups-before-setuid.

(In reply to Jan Ritzerfeld from comment #2)
> POS36-C: "Consequently, it is recommended that a program relinquish
> supplementary group IDs immediately before relinquishing root privileges."
> rpmlint warns about a missing-call-to-setgroups-before-setuid.

That is the reason why the setgroup is there:

@@ -1277,6 +1278,7 @@ disable_priv_mode ()
 {
   int e;
 
+  setgroups(0, NULL);
   if (setuid (current_user.uid) < 0)
     {
       e = errno;


...maybe the initgroups(3) (g)libc call would be better as this does inherent setgroups(2) with users groups as well.  Also it would help if rpmlint would mention initgroups(3) as the better option

Was it ever submitted upstream? Was it rejected? If yes, why?

In any case, upstream or not, this needs documentation. Behavior is entirely undocumented, not even in changelog, and is incompatible with other distributions and upstream.

(In reply to Andrei Borzenkov from comment #4)
> Was it ever submitted upstream? Was it rejected? If yes, why?
> 
> In any case, upstream or not, this needs documentation. Behavior is entirely
> undocumented, not even in changelog, and is incompatible with other
> distributions and upstream.

This was a simple left over done to silent the rpmlint messages for an other bug. I had never added this to changelog as it slipped out.

(In reply to Mark Hounschell from comment #0)
> I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0
> install and ported over the source code that we ran on the 13.2 box. It
> builds fine but I am having an issue. The program is/has to be an suid pgm.
> It also uses fork/execvpe/wait to execute some external scripts. And that is
> where my problem lies. The user is a member of several groups but these
> group memberships seem to disappear when these external scripts are
> executed. For instance the user is a member of the cdrom group so he can
> eject and work with a DVD. I have created a simple example script and source
> for a pgm that execvpe's that script which shows my problem.

You might give version of the latest bash in project Base:System a try as here I have replaced the setgroup(2) system call with the initgroup(3) libc call:

https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm


If this works for you I'll submit the fix tu upstream and will see if Chet does accept this.

https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm

This did not work for me. Same results. Did it work for you with the provided test case?

(In reply to Mark Hounschell from comment #6)
> https://rudin.suse.de:8894/package/binary/download/Base:System/bash/
> openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm
> 
> This did not work for me. Same results. Did it work for you with the
> provided test case?

Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with fixing that I see

abuild@noether:/tmp> cat checkgrp.c
#define _GNU_SOURCE
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
    char *path = getenv("PATH");
    char  pathenv[strlen(path) + sizeof("PATH=")];
    sprintf(pathenv, "PATH=%s", path);
    char *envp[] = {pathenv, NULL};
    char *tests[] = {"/tmp/id.sh", NULL};
    execvpe(tests[0], tests, envp);
}
abuild@noether:/tmp> cat id.sh
#!/bin/sh
whoami
id
abuild@noether:/tmp> ll
total 32
-rw------- 1 root   root     101 Jun  4 10:43 .xauthEJxh4h0IyV
-rwsr-sr-x 1 root   root   16936 Jun  4 10:48 checkgrp
-rw-r--r-- 1 abuild abuild   352 Jun  4 10:48 checkgrp.c
-rwxr-xr-x 1 abuild abuild    20 Jun  4 10:48 id.sh
abuild@noether:/tmp> ./checkgrp 
abuild
uid=399(abuild) gid=399(abuild) groups=399(abuild),488(video),489(tape),495(cdrom),496(audio)

>Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with >fixing that I see"

I don't see that SIGSEGV. Might I ask what you did to fix that. In any case I double checked, I still loose my group memberships using the rpm you pointed me to.

(In reply to Mark Hounschell from comment #8)
> >Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with >fixing that I see"
> 
> I don't see that SIGSEGV. Might I ask what you did to fix that. In any case
> I double checked, I still loose my group memberships using the rpm you
> pointed me to.

You might retry the now latest

https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.362.1.x86_64.rpm

as this includes the fixed version

Yes, that one seems to work properly for me in my test case and in my application.

I don't understand how 
" POS36-C: "Consequently, it is recommended that a program relinquish
> supplementary group IDs immediately before relinquishing root privileges."

would affect the original submitter.

The problem was the loss of supplementary group ID's upon becoming root,
where as the POS36C section that was quoted says to relinquish such ID's
before relinquishing root privs.

As an aside -- since it was an SUID program it would relinquish it's root privs
upon exit, so it seems pointless to relinquish any groups as the process
goes away.  Maybe in some other circumstance that wouldn't be the case, but 
the 1st point still stands -- the POS36c statement above doesn't say to relinquish
groups upon becoming root, but on transitioning away from root.

Ideally, the groups active at the beginning of a root session would be
those retained when transitioning away from root.  I.e this would put things
back exactly the way before the UID change.  No doubt it is a fear of people not getting it right and having additional groups added as root that propagate to a user.

However, reiterating:

the above POS36 **recommendation** (not requirement), only would seem to apply when transitioning away from root -- so the original submitter should not have encountered a problem.

(In reply to L. A. Walsh from comment #11)
> [...]
> The problem was the loss of supplementary group ID's upon becoming root [...]

Actually, his problem was the loss of supplementary group IDs when transitioning away from root.

This is an autogenerated message for OBS integration:
This bug (1095670) was mentioned in
https://build.opensuse.org/request/show/621861 Factory / bash

Submit requests running

Try SR#173129

SUSE-RU-2018:3079-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1095661,1095670,1100488
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15 (src):    bash-4.4-9.7.1

openSUSE-RU-2018:3139-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1095661,1095670,1100488
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    bash-4.4-lp150.8.3.1