Passenger on Big Sur potential privilege escalation vulnerability detected - homebrew

New installation of Passenger using homebrew on Big Sur. Because of the new location (I'm coming from an El Capitan box) of homebrew installations inside /opt/homebrew, Passenger isn't happy because it's something I can see from the set permissions. The error:
2021/03/19 09:22:16 [warn] 85#0: 1024 worker_connections exceed open file resource limit: 256
[ N 2021-03-19 09:22:16.2962 31353/T1 age/Wat/WatchdogMain.cpp:1373 ]: Starting Passenger watchdog...
[ N 2021-03-19 09:22:16.3519 31355/T1 age/Cor/CoreMain.cpp:1340 ]: Starting Passenger core...
[ N 2021-03-19 09:22:16.3521 31355/T1 age/Cor/CoreMain.cpp:256 ]: Passenger core running in multi-application mode.
[ W 2021-03-19 09:22:16.3944 31355/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 (/opt/homebrew/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini) can be changed by non-root user(s):
- /opt/homebrew/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini is not secure: it can be modified by user rich
- /opt/homebrew/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger is not secure: it can be modified by user rich
- /opt/homebrew/opt/passenger/libexec/src/ruby_supportlib is not secure: it can be modified by user rich
- /opt/homebrew/opt/passenger/libexec/src is not secure: it can be modified by user rich
- /opt/homebrew/opt/passenger/libexec is not secure: it can be modified by user rich
- /opt/homebrew/opt/passenger is not secure: it can be modified by user rich
- /opt/homebrew/opt is not secure: it can be modified by user rich
- /opt/homebrew is not secure: it can be modified by user rich
It is a warming, but I'm not sure if it's limping or fully functional.
Should I worry? Should I change anything? Will this go away? Seems it's been designed this way, but I see warnings.
Any insight appreciated. Thank you.

Related

mod_fcgid: read data timeout in 45 seconds and Premature end of script headers: index.php

One of my website clients had issues while placing orders.
When I checked my error log I could see this :
[warn] mod_fcgid: read data timeout in 45 seconds, referer: https://myDomain/cart
[error] Premature end of script headers: index.php, referer: https://myDomain/cart
What does this error mean? What should I do to eliminate this error? Are there any settings to be changed in Plesk Control panel? will it be solved if I change 'max_execution_time' in 'Php settings' to 3600?
I am using Plesk 12.0.18, CentOS 5.11
The error means that website code in index.php file fails to be executed in the time limit, which set for Apache FastCGI module and/or PHP.
Most likely, there is an error in the index.php, which makes it inoperable at all. In this case, you should increase the PHP error reporting level in Plesk > Domains > example.com > PHP Settings and review the script itself.
Less likely that script is meant to take a long time to execute. In this case, you may simply increase timeout via Plesk. To set 120 seconds instead of default 45, do the following:
1. Set max_execution_time to 120 in Plesk > Domains > example.com > PHP settings.
2. Increase FastCGI timeout by adding the following Apache dirctives in Plesk > Domains > example.com > Apache & Nginx settings > Additional Apache directives:
<IfModule mod_fcgid.c>
FcgidIOTimeout 120
</IfModule>

Rails.application.database_configuration error with Rails 5.1 + Nginx + Phusion_Passenger

I have a server with Rails 5.1, Phusion_Passenger and Nginx.
When I start the server with just Phusion_Passenger, all is good:
=============== Phusion Passenger Standalone web server started ===============
PID file: /project/tmp/pids/passenger.3000.pid
Log file: /project/log/passenger.3000.log
Environment: development
Accessible via: http://0.0.0.0:3000/
You can stop Phusion Passenger Standalone by pressing Ctrl-C.
Problems? Check https://www.phusionpassenger.com/library/admin/standalone/troubleshooting/
===============================================================================
[ N 2017-09-26 15:13:06.4195 8753/T5 age/Cor/SecurityUpdateChecker.h:374 ]: Security update check: no update found (next check in 24 hours)
When I try to start and access the same instance with Nginx as the overlay, I get the following error:
App 8129 stdout:
App 8129 stdout:
[ E 2017-09-26 15:06:26.4848 1774/T1l age/Cor/App/Implementation.cpp:304 ]: Could not spawn process for application /project: An error occurred while starting up the preloader.
Error ID: e18b79ab
Error details saved to: /tmp/passenger-error-YkowRo.html
Message from application: Cannot load `Rails.application.database_configuration`:
undefined method `[]' for nil:NilClass (NoMethodError)
(erb):13:in `<main>'
It seems that when you load the rails app with Nginx, it cannot access the "Rails" object.
Passenger does not have a default environment set in the passenger.conf. Added this variable and it fixed the problem.
passenger_app_env development;

AWS Elastic Beanstalk Error - Passenger

I've tried various solutions that are intuitive and then have tried the solutions that have apparently helped others. I've spun up and terminated my Rails 4 app about 10 times. So...I thought I'd turn here to see if anyone knew an answer.
Here is the log file:
[ 2015-03-06 06:12:27.0070 2619/7fa0f6d60740 agents/Watchdog/Main.cpp:538 ]:
Options: { 'analytics_log_user' => 'webapp', 'cleanup_pidfiles' =>
'L3RtcC9wYXNzZW5nZX*********************yL3RlbXBfZGlyX3RvdWNoZXIucGlk',
'default_group' => 'webapp', 'default_python' => 'python', 'default_ruby' =>
'/opt/rubies/ruby-2.1.5/bin/ruby', 'default_user' => 'webapp', 'log_level' =>
'0', 'max_pool_size' => '6', 'passenger_root' => '/tmp/passenger-
standalone.1fcb7jr/locations.ini', 'passenger_version' => '4.0.53',
'pool_idle_time' => '300', 'prestart_urls' => 'aHR0cDovLzAuMC4wLjA6ODAA',
'temp_dir' => '/tmp', 'union_station_gateway_address' =>
'gateway.unionstationapp.com', 'union_station_gateway_port' => '443',
'user_switching' => 'false', 'web_server_passenger_version' => '4.0.53',
'web_server_pid' => '2618', 'web_server_type' => 'nginx',
'web_server_worker_gid' => '496', 'web_server_worker_uid' => '497' }
[ 2015-03-06 06:12:27.3877 2622/7fac802f6740 agents/HelperAgent/Main.cpp:650]:
PassengerHelperAgent online, listening at
unix:/tmp/passenger.1.0.2618/generation-0/request
[ 2015-03-06 06:12:28.2222 2630/7fe1e0b67740 agents/LoggingAgent/Main.cpp:321
]: PassengerLoggingAgent online, listening at
unix:/tmp/passenger.1.0.2618/generation-0/logging
[ 2015-03-06 06:12:28.2223 2619/7fa0f6d60740 agents/Watchdog/Main.cpp:728 ]:
All Phusion Passenger agents started!
2015/03/06 06:12:29 [error] 2638#0: *3 "/var/app/current/public/index.html" is
not found (2: No such file or directory), client: 127.0.0.1, server: _,
request: "HEAD / HTTP/1.1", host: "0.0.0.0"
2015/03/06 06:13:35 [error] 2638#0: *7 "/var/app/current/public/index.html" is
not found (2: No such file or directory), client: 172.3*.**.***, server: _,
request: "GET / HTTP/1.1", host: "****************-env.elasticbeanstalk.com"
I have gem 'passenger' in my gem file...I have tried in both development (because I've seen a number of errors with production and passenger) and production and I swear I have never had this kind of trouble uploading to elastic beanstalk. In fact this is a very stripped down app with only a static page and both devise for a user and devise for active admin. No errors or problem in either environment on my local machine.
I've never even realized I needed the index.html file...I always assumed that was only in php and other languages and that Rails took care of that for you with root. And like I said I've never seen this problem before. So to test that I put in an index.html file in the public folder and I could see that ahead of my root route on my local machine, but still no dice in AWS. I'd prefer to be able to drop this in and one of the other configs like just Puma. And I see a Puma and Nginx config available, but not in the GUI which is what I was planning to just "drop" this in and be done with it for the time being. I'm using a t2.small instance.
Any help or direction would be greatly appreciated. Thanks.
UPDATE: I've now tried this pushing through Git using Puma...etc. Trouble everywhere. It makes no sense. I even moved it to a "Hello World" app and still nothing. I'm about done with AWS. This is ridiculous. Nearly worse than an iOS release that has massive problems every year.
Ok. After today I have gotten this taken care of and hosted properly. In case this helps someone out...here were the key takeaways:
1) There is a Puma option if you are using CLI that is obvious. There is ALSO an option in the GUI, however it reads like a sentence instead of a logical select box. It DOES exist on the front page underneath the selection of the language to be installed. If you are getting a Passenger Error and expect to be using Puma, this is something you need to change.
2) I had installed a User model that contained an ActiveAdmin role as well. ActiveAdmin was pulling the gem from GitHub and I am using a machine with GitHub installed already. This really was the problem...switching to production and onto ElasticBeanstalk I forgot that git wasn't already installed. After going back through the errors many times, the common error was
# :github => 'activeadmin/activeadmin'+ '[' -d /vendor/cache ']'
+ bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break this application for all non-root
users on this machine.
You need to install git to be able to use gems from git repositories.
[CMD-Startup/StartupStage0/AppDeployPreHook/10_bundle_install.sh] : Activity failed.
This is located in the eb-activity.log.
So, if this is similar to anything happening to you, you can do as follows:
1) start up your instance with the correct server.
2) if you get an error, look through that activity log mentioned above. (All the logs for that matter)
3) If the error fails similarly there is NO NEED to delete the instance. Leave it running.
4) SSH into the server instance that you just created. Run
sudo yum update
that is more than likely recommended. And then run
sudo yum install git
5) Upload the same exact file and name the version 0.1 and when it's through it should be green if this was your only error. Click the link and Voila.
For the git binary problem: It will fail again, if more instances are spinning up. You can avoid that by adding a config under $ROOT/.ebextensions which will be used for any new instance.
# Install git in order to be able to bundle gems from git
packages:
yum:
git: []

Prepared data set "Musicbrainz" doesn't work - Detected incorrectly shut down database, performing recovery

I struggling to get the "Musicbrainz" data set running on my local machine (MacBook Air, Mountain Lion).
What I did? (Basically what the video said)
Downloaded data set directly from http://www.neo4j.org/develop/example_data
Downloaded fresh Neo4j-Community-2.1.5
Extracted the data set, renamed it to graph.db and copied to /neo4j-community-2.1.5/data/graph.db
Run the server: ./bin/neo4j console, but neo does not start - not even an exception is thrown!!!!
Gerardos-MacBook-Air:neo4j-community-2.1.5 Gery$ ./bin/neo4j console
WARNING: Max 256 open files allowed, minimum of 40 000 recommended.
See the Neo4j manual. Starting Neo4j Server console-mode... Using
additional JVM arguments: -server -XX:+DisableExplicitGC
-Dorg.neo4j.server.properties=conf/neo4j-server.properties -Djava.util.logging.config.file=conf/logging.properties -Dlog4j.configuration=file:conf/log4j.properties -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled 2014-10-09 15:40:31.700+0000 INFO [API] Setting startup timeout to: 120000ms
based on -1 Detected incorrectly shut down database, performing
recovery..
I tried several settings in neo4j.properties, but nothing, see properties below ...
use_memory_mapped_buffers=true
neostore.nodestore.db.mapped_memory=300M
neostore.relationshipstore.db.mapped_memory=3G
neostore.propertystore.db.mapped_memory=500M
neostore.propertystore.db.strings.mapped_memory=500M
neostore.propertystore.db.arrays.mapped_memory=0M
neostore.propertystore.db.index.keys.mapped_memory=15M
neostore.propertystore.db.index.mapped_memory=15M
allow_store_upgrade=true
I was hoping that this would work out of the box. What am I missing ...?

Thinking Sphinx min_inflex_len and delta not working on production server

We have an issue with TS min_inflex_len and delta indexes on our production servers
I have everything working in development mode on OSX but when we deploy via capistrano to our Ubuntu server running passenger / apache, both delta indexing seems to stop as well as min_inflex_len
We're deploying as ubuntu user which also runs apache. We had an issue yesterday with production folder not being created but we manually created and I can see a list of the delta files in there now.
I've followed the docs through..
I can see the delta flag set to true on record creation but when searching it doesn't find the record. Once we rebuild index (as ubuntu user) I can find record, but only with full string.
My sphinx.conf file is as follows:
production:
enable_star: 1
min_infix_len: 3
bin_path: "/usr/local/bin"
version: 2.0.5
mem_limit: 128M
searchd_log_file: "/var/log/searchd.log"
development:
min_infix_len: 3
bin_path: "/usr/local/bin"
version: 2.0.5
mem_limit: 128M
Rebuild, start and conf work fine and my production.conf file contains this:
index company_core
{
source = company_core_0
path = /var/www/html/ordering-main/releases/20110831095808/db/sphinx/production/company_core
charset_type = utf-8
min_infix_len = 1
enable_star = 1
}
I also have this in my production.rb env file:
ThinkingSphinx.deltas_enabled = true
ThinkingSphinx.updates_enabled = true
My searchd.log file only has this in:
[Wed Aug 31 09:40:04.437 2011] [ 5485] accepting connections
Nothing at all appears in apache error / access log
-- EDIT ---
define_index do
indexes :name
has created_at, updated_at
set_property :delta => true
end
Not sure if it's the cause, but the version values in your sphinx.yml are for the version of Sphinx, not Thinking Sphinx - so you may want to run indexer to double-check what that value should be (likely one of 0.9.9, 1.10-beta or 2.0.1-beta).
Also: on the server, in script/console production, can you share the full output of the following (not interested in the value returned, hence why I'm forcing it to be an empty string - it'll just get in the way otherwise):
Company.define_indexes && Company.index_delta; ''
``
delta not working on production server for passenger user, you have to give the write permission to your passenger user when creating index and write it to db/sphinx/production folder.
Or you can set two line in your nginx/conf/nginx.conf
passenger_user_switching off;
passenger_default_user root;
Example:
passenger_root /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.0;
passenger_ruby /usr/local/bin/ruby;
passenger_user_switching off;
passenger_default_user root;

Resources