Apparent problem retrieving gid list for application-owning userid under mod_passenger v5.3.0, (causes app init failure)

[MacGuinness]

Issue report

Are you sure this is a bug in Passenger?
99.9% positive -- a previously-working application stops loading following upgrade from 5.2.3 to 5.3.0. No other changes made. Can revert upgrade and restore function. Can repeat on other systems with similar configurations/setup.

Please try with the newest version of Passenger to avoid issues that have already been fixed
Newest version (5.3.0) introduces the problem...

Question 1: What is the problem?
We have one of three applications running under a single virtualhost on our RHEL6/apache+mod_passenger dev server, that has begun failing to initialize/load immediately following the upgrade of this system to passenger-5.3.0. (Upgrade successfully using yum/RPMs...)

One of the three apps is failing to initialize, the other two test apps are working correctly.

The error reported is:

"The Phusion Passenger application server tried to start the web application as user 'web.liac' and group 'aces-web_passenger-apps'. During this process, Passenger must be able to access its application root directory '/export/dev/L/pastest.itcs.illinois.edu/public/apps/default'. However, the parent directory '/export/dev/L/pastest.itcs.illinois.edu' has wrong permissions, thereby preventing this process from accessing its application root directory."

The "failing" app works again if the system is restored to the previous version. (revert to VM snapshot...)

The difference between the working apps and failing app is:

• files/dirs at /export/dev/L/pastest.itcs.illinois.edu and below are owned by user:web.tester...
• EXCEPT for files at/below /export/dev/L/pastest.itcs.illinois.edu/public/apps/default, which are owned by user:web.liac.
• both users above are members of the group-owner: aces-web_liac.aces.illinois.edu_full, used across this entire branch.
• both users above have the same primary group: aces-web-passenger-apps

Also of Note: the directory where the access is being blocked (/export/dev/L/pastest.itcs.illinois.edu) has permissions set to drwxrwx--- in order to block access (including directory traversal) from non-members of the group-owner.

With passenger-5.3.0 installed, and looking at the Detailed diagnostics -> Subprocess tab of the error page, I see the following erroneous information displayed under User and group:

uid=1890123039(web.liac) gid=1890123038(aces-web_passenger-apps) groups=1890123038(aces-web_passenger-apps),49,793070128,1559814600,1702063727,1702130479,1886610802,1919967861,1932489584,1936024431,1953576024

Note: gids: 49,793070128,1559814600,1702063727,1702130479,1886610802,1919967861,1932489584,1936024431,1953576024 are completely invalid...

For comparison, running the id command in a terminal as user: web.liac:

$ id
uid=1890123039(web.liac) gid=1890123038(aces-web_passenger-apps) groups=1890123038(aces-web_passenger-apps),41229(AW_gid-web.liac),42191(AW_liac.aces.illinois.edu),466099856(AWl_liac.aces.illinois.edu),1890058753(uofi-domain-users),1890069947(kcpa_...),1890121190(aces-web_liac.aces.illinois.edu_full),1890193658(aces-web_site-maintainers),1890346257(atlas-...),1890455566(kch-...),1890455567(kch-...),1890459066(bio...)

$ id -G
1890123038 41229 42191 466099856 1890058753 1890069947 1890121190 1890193658 1890346257 1890455566 1890455567 1890459066

As one can see, all the groups returned by the id -G command for the user (after the first/primary group) are completely different than what mod_passenger reports.

Also, 11 gids are returned under mod_passenger for the userid, but 12 gids are returned by the id commands.

This tells me that the group-list obtained for the app's userid by mod_passenger is rather completely compromised/hosed in some fashion. Only the first entry (the userid's primary group (gid)) is correctly obtained/listed.

This bad group information being retrieved under mod_passenger is then causing the directory-traversal failure at the path-location noted in the error message above.

I am able to restore function for the app in the following ways:

1. using setfacl to add a traverse-only ACL for the app's userid: web.liac
setfacl -m u:web.liac:--x /export/dev/L/pastest.itcs.illinois.edu

2. using setfacl to add a traverse-only ACL for the app's userid's primary group: aces-web_passenger-apps
setfacl -m g:aces-web_passenger-apps:--x /export/dev/L/pastest.itcs.illinois.edu

Attempts to add like ACLs for the other legitimate groups listed by id for the userid fail to have any effect.

Question 2: Passenger version and integration mode:
open source 5.3.0 standalone

Question 3: OS or Linux distro, platform (including version):
RHEL6, x86_64

Question 4: Passenger installation method:
[X] Phusion YUM repo

Question 5: Your app's programming language (including any version managers) and framework (including versions):
Ruby 2.2.3 (not that it really matters, in this case...)

Question 6: Are you using a PaaS and/or containerization? If so which one?
None

[FooBarWidget]

Thanks for submitting this bug report, and sorry about the issue. Could you attach the error page (HTML) that Passenger generated? It contains more details that would help us analyze the problem. Feel free to redact any secrets that the page may contain.

[FooBarWidget]

To @CamJN and @OnixGH: the fact that the bug report says that the id output differs from the expected output, suggests that there is a bug in our user switching code. Specifically, SpawnEnvSetupperMain.cpp function switchGroup(). Maybe we aren't doing a good job setting the supplementary group IDs there? Please review.

Perhaps one of you could write a small test program for the submitter, which simulates switchGroup() and tests whether our code behaves as expected on the submitter's system.

[CamJN]

Here is a test program you can compile with g++ (yum install -y gcc-c++) on rhel6 and run as ./a.out username groupname (where username and groupname are a real user name, group name pair) to check our group changing logic.

[FooBarWidget]

We've found the issue and pushed a fix. We'll release a new version with the fix soon. Thanks again for reporting the issue!