search

phusion / passenger

A fast and robust web server and application server for Ruby, Python and Node.js
https://www.phusionpassenger.com/
MIT License
5k stars 547 forks source link

Effective id "nobody" on Apache on macOS Big Sur #2320

Closed rubys closed 3 years ago

rubys commented 3 years ago

Please follow the steps below if you have found an issue with Passenger, or would like to request a feature.

Post to Stack Overflow instead if you are not sure, or if you have a question about your configuration.

Issue report

Fill in as much as possible so that we can understand, find and fix the problem.

Are you sure this is a bug in Passenger? Please read our troubleshooting and debugging guides first: https://www.phusionpassenger.com/library/admin/troubleshooting/ https://www.phusionpassenger.com/library/admin/

Please try with the newest version of Passenger to avoid issues that have already been fixed

Question 1: What is the problem?

Be as detailed as possible in your descriptions, include any logs and stack traces (don't just cut/paste the error, provide some logging before that too).

(if you are requesting a feature instead of reporting an issue, describe here what you have in mind and how it would help you)

Your answer:

On a fresh install of Big Sur with the following configuration, I get Errno::EACCES in my application:

  LoadModule passenger_module /usr/local/opt/passenger/libexec/buildout/apache2/mod_passenger.so
  PassengerRoot /usr/local/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini
  PassengerDefaultRuby /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
PassengerUser _www
PassengerGroup _www

Adding STDERR.puts `id` produces:

uid=4294967294(nobody) gid=4294967294(nobody)

The same application works with macOS Catalina.

Note: I did see messages scrolling by when I installed passenger that macOS Big Sur was not (yet) a supported configuration, I'm just reporting the specific failure I'm seeing in case it is helpful.

Question 2: Passenger version and integration mode:

Your answer:

Phusion Passenger 6.0.6

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

Your answer:

% sw_vers
ProductName:    macOS
ProductVersion: 11.0.1
BuildVersion:   20B29

Note: this is a clean install. I upgraded this laptop from macOS Catalina, saw a number of things were broken, so I did a factory reset: erased my hard drive and reinstalled the OS cleanly.

Question 4: Passenger installation method:

Your answer: [ ] RubyGems + Gemfile [ ] RubyGems, no Gemfile [ ] Phusion APT repo [ ] Phusion YUM repo [x] OS X Homebrew [ ] source tarball [ ] Other, please specify:

Question 5: Your app's programming language (including any version managers) and framework (including versions):

Your answer:

ruby 2.6.3p62, sinatra (2.1.0)

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

Your answer:

No.

Question 7: Anything else about your setup that we should know?

Your answer:

I believe that the above captures all that is needed, but if it helps, the way passenger was installed was by running the following script:

https://github.com/apache/whimsy/blob/master/config/setupmymac

Using the following instructions: https://github.com/apache/whimsy/blob/master/SETUPMYMAC.md#simple-whimsylocal-installation

We strive for quality and appreciate you taking the time to submit a report! Please note that if you want guaranteed response times and priority issue support we encourage you to join our enterprise customer base. They also provide us with the means to continue our high level of open source support!

CamJN commented 3 years ago

From the whimsy docs it looks like you might be starting apache as your own user instead of having macOS start it via launchd? Is that correct? If that's the case, make sure you have the ability to switch users to _www without sudo, otherwise Passenger cannot change users properly for you, and will wind up using the nobody user to run your app. The apache error log should have more details, though if you are running apache yourself, I don't know if the logs wind up in /var/log/apache2/error_log as usual, or somewhere else.

When running apache via launchd (started by apachectl start) which starts apache as root, Passenger is able to switch users to _www correctly. It may be that in Catalina you had given your user the ability to switch users to _www without a password, but haven't done that in Big Sur yet, or it may be Apple has added new restrictions for doing so.

rubys commented 3 years ago

The server was started with:

sudo apachectl restart

Output of ps, running as root:

# ps -eO uid  | grep httpd
32518     0   ??  Ss     0:00.39 /usr/sbin/httpd -D FOREGROUND
32688    70   ??  S      0:00.08 /usr/sbin/httpd -D FOREGROUND
32772    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32773    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32774    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32776    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32777    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32778    70   ??  S      0:00.01 /usr/sbin/httpd -D FOREGROUND
32779    70   ??  S      0:00.00 /usr/sbin/httpd -D FOREGROUND
32847     0 s001  S+     0:00.00 grep httpd

the owner of id 70:

# id 70
uid=70(_www) gid=70(_www) groups=70(_www),12(everyone),61(localaccounts),701(com.apple.sharepoint.group.1),100(_lpoperator)

P.S. I have two similarly configured laptops, one running Catalina and one running Big Sur, so if there is anything you want me to compare, don't hesitate to ask...

CamJN commented 3 years ago

Hmm, I setup a Big Sur vm and tested running a ruby app as both my user and _www and in both cases passenger changed users fine. Can you set PassengerLogLevel to 7 and check the logs for anything that stands out?

rubys commented 3 years ago

@CamJN, did you install passenger via brew? I ask because after altering the log level, I am now seeing the following:

[ N 2020-11-14 18:56:59.2291 17472/T1 age/Cor/CoreMain.cpp:1340 ]: Starting Passenger core...
[ N 2020-11-14 18:56:59.2296 17472/T1 age/Cor/CoreMain.cpp:256 ]: Passenger core running in multi-application mode.
[ W 2020-11-14 18:56:59.2631 17472/T1 age/Cor/CoreMain.cpp:1007 ]: WARNING: potential privilege escalation vulnerability detected. Phusion Passenger is running as root, and part(s) of the Passenger root path (/usr/local/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini) can be changed by non-root user(s):

 - /usr/local/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini is not secure: it can be modified by user rubys
 - /usr/local/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger is not secure: it can be modified by user rubys
 - /usr/local/opt/passenger/libexec/src/ruby_supportlib is not secure: it can be modified by user rubys
 - /usr/local/opt/passenger/libexec/src is not secure: it can be modified by user rubys
 - /usr/local/opt/passenger/libexec is not secure: it can be modified by user rubys
 - /usr/local/opt/passenger is not secure: it can be modified by user rubys
 - /usr/local/opt is not secure: it can be modified by user rubys

Please either fix up the permissions for the insecure paths, or install Passenger in a different location that can only be modified by root.
[ N 2020-11-14 18:56:59.2631 17472/T1 age/Cor/CoreMain.cpp:1015 ]: Passenger core online, PID 17472
[Sat Nov 14 18:56:59.266055 2020] [mpm_prefork:notice] [pid 17448] AH00163: Apache/2.4.46 (Unix) Phusion_Passenger/6.0.6 configured -- resuming normal operations
[Sat Nov 14 18:56:59.266279 2020] [core:notice] [pid 17448] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[ N 2020-11-14 18:56:59.9776 17463/T1 age/Cor/CoreMain.cpp:1325 ]: Passenger core shutdown finished
[ N 2020-11-14 18:57:02.0437 17472/T5 age/Cor/SecurityUpdateChecker.h:519 ]: Security update check: no update found (next check in 24 hours)
App 17537 output: uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody),12(everyone),61(localaccounts),701(com.apple.sharepoint.group.1),100(_lpoperator)
App 17537 output: 2020-11-14 18:57:04 - Errno::EACCES - Permission denied @ rb_sysopen - /srv/agenda/cache/board_agenda_2020_11_18.yml

Those files are owned by rubys/staff on both of my machines, I am running passenger 6.0.6 on both, but I only see the failure on Big Sur.

rubys commented 3 years ago

I see the same potential privilege escalation vulnerability on MacOS Catalina, however the request is processed successfully there.

CamJN commented 3 years ago

Yes, you should see the permissions warning in both cases, but that's normal for a homebrew installed passenger. There should be some more logs though if you set PassengerLogLevel to 7. This looks like the default log level is still in effect.

For example log level 7 shows what effect the .bash_profile has on app startup.

rubys commented 3 years ago

I do, indeed, have plenty of log output, including my user and password base64 encoded, and the following line:

   "log_level" : 7,

Is there something specific I am looking for? The excerpt I provided previously was contiguous log lines, seemed to indicate that passenger was indeed running as root, and contained the output of the id command when running as the application.

CamJN commented 3 years ago

I replaced my built from source passenger with the one from homebrew, and still couldn't reproduce the issue in my vm, so i'm not sure exactly what I'm looking for in the logs, just things that seem off. For example in the app spawn arg output, are user and group correctly reported as _www? Is the startup_file what you expect? What does the user_switching in the passenger core config say?

Can you check what this outputs? sudo -u _www ls -l /path/to/your/app/config.ru

rubys commented 3 years ago

in the app spawn arg output, are user and group correctly reported as _www?

On Catalina, yes; on Big Sur no.

On Big Sur, the user and group are nobody

Is the startup_file what you expect

Yes, on both

What does the user_switching in the passenger core config say?

On both:

   "user_switching" : true,

Can you check what this outputs? sudo -u _www ls -l /path/to/your/app/config.ru

# sudo -u _www ls -l /srv/whimsy/www/board/agenda/config.ru
-rw-r--r--  1 rubys  staff  1731 Nov 14 17:48 /srv/whimsy/www/board/agenda/config.ru

The output is the same on both machines (with the exception of the date/time stamp)

CamJN commented 3 years ago

Maybe try diffing the error log from the catalina and big sur apache startups both with the raised log level?

You can filter out a bunch of irrelevant lines with fgrep -vie 'Statistics' -e turbocache -e Analytics -e metrics -e 'Garbage collection' -e telemetry /var/log/apache2/error_log which should minimize the number of lines that don't match up due to timing differences.

You don't have to post the results, as you've got sensitive info in the logs, but perhaps it will highlight what's going wrong.

rubys commented 3 years ago

My apologies, false alarm. This issue can be closed, but I do have a minor suggestion, see below.

For context, whimsy is an application that normally runs on Ubuntu, but for convenience for developers, a script is provided that replicates the configuration for MacOS users. I didn't realize it, but a Ubuntu specific change had been introduced recently into the configuration:

https://lists.apache.org/thread.html/ra2e081b03eca6c7c65cacb009b0eac6674b8de1861300e02cc45b76e%40%3Ccommits.whimsical.apache.org%3E

The problem is that www-data is not a user that is commonly present on MacOS machines. I first picked up this change when I did a clean install, and mistakenly assumed that the problem I was seeing was due to Big Sur. When trying to clean up my Catalina installation so that I could capture a true apples-to-apples log comparison, I first replicated the problem on Catalina and then tracked down the change.

It seems perfectly reasonable for Passenger to treat an attempt to change to non-existent user ids to change to nobody. My one suggestion is that when this occurs, it should be logged; preferably on a log level that would show up by default.

Thanks for working with me as I worked through this.

CamJN commented 3 years ago

Yeah I agree about the warning in case of an unknown user, and i'm glad you got this sorted!

rubys commented 3 years ago

I agree about the warning in case of an unknown user

Would it be helpful if a separate issue were opened to track that change?

CamJN commented 3 years ago

Sure thing