I configured 2 mod_wsgi daemons with 2 different os users and groups. Apache will properly spawn a daemon for each user:
# ps -eF
root 10188 1 0 4586 6204 0 09:21 ? 00:00:00 /usr/sbin/httpd
501 10190 10188 0 50531 13592 0 09:21 ? 00:00:00 /usr/sbin/httpd
500 10191 10188 0 48336 5936 0 09:21 ? 00:00:00 /usr/sbin/httpd
apache 10192 10188 0 4867 7300 0 09:21 ? 00:00:00 /usr/sbin/httpd
...
So far it works fine, each request contains the configured mod_wsgi.process_group.
However, when file system privileges of the document root are restricted to the daemon user (chmod -R 700), apache will yield an access denied message in the vHost's error log:
"(13)Permission denied: access to / denied"
I wonder why I need to have public read access, when the files are supposed to be accessed by the daemon only?
Note: this happens also when selinux is turned off.
Apache needs at least search access (+x) to the directories down to where the WSGI script file is located. This is needed when mapping the URL to the WSGI script file so it can determine if the WSGI script file exists.
Another alternative is to have the WSGI script file in an area outside of the protected directories and then have the WSGI script import a specific Python module from the protected area which contains the actual WSGI application. The WSGI script files could be set up by system admins and not something writable by users.
Related
I am trying to change the document root on my Ubtuntu 18.04 OpenLiteSpeed server. I would like to change it to /var/www/html/public so I can install my Laravel project there. It's where I am used to having my document root from Apache. I have found the settings within the admin panel (it is now set to /var/www/html/public); however, it seems from other posts that I have found that the user does not have the correct permissions (I get a 500 error when visiting the site). I am wondering how I go about changing those permissions.
# ps -ef|grep litespeed
Returns
root 24011 1 0 22:06 ? 00:00:00 openlitespeed (lshttpd - main)
root 24012 24011 0 22:06 ? 00:00:00 openlitespeed (lscgid)
nobody 24021 24011 0 22:06 ? 00:00:00 openlitespeed (lshttpd - #01)
nobody 24022 24011 0 22:06 ? 00:00:00 openlitespeed (lshttpd - #02)
root 24095 20775 0 22:15 pts/0 00:00:00 grep --color=auto litespeed
Please try set up suexec user/group as this (the last 2 options) to your external app setting, accordingly to your /var/www/html/public owner/group.
but 500 error not necessarily means permission issue.
You can also try create a simple hello world or phpinfo page to test first.
I have Django setup in NGINX + uWSGI. I'm able to get it running fine under my current logged in user (with help from a question I asked few days back) but now I want to run uwsgi --ini uwsgi.ini as a limited-access user.
Here is what I've done so far:
1. Created a user djangouser without login access and without a home directory.
2. Added user nginx into group djangouser
3. Placed my django files into /mnt/django directory and changed file permissions of django to drwxrwx--- djangouser djangouser (recursive)
4. Changed the conf files to match the file locations
uwsgi.ini file
[uwsgi]
chdir=/mnt/django/project/awssite
module=awssite.wsgi
home=/mnt/django/project
master=true
processes=2
uid=djangouser
gid=djangouser
socket=/mnt/django/djangosocket/awssite.socket
chmod-socket
vacuum=true
When I try to run uwsgi --ini uwsgi.ini, this is the error I get
[uWSGI] getting INI configuration from uwsgi.ini
*** Starting uWSGI 2.0.12 (64bit) on [Thu Feb 18 00:18:25 2016] ***
compiled with version: 4.8.3 20140911 (Red Hat 4.8.3-9) on 01 February 2016 04:17:11
os: Linux-4.1.13-19.31.amzn1.x86_64 #1 SMP Wed Jan 20 00:25:47 UTC 2016
nodename: ip-10-200-1-89
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ec2-user
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /mnt/django/project/awssite
chdir(): Permission denied [core/uwsgi.c line 2586]
chdir(): Permission denied [core/uwsgi.c line 1608]
Note: When I added my logged in user to djangouser group, uwsgi --ini uwsgi.ini ran fine and I was able to load the django pages.
I'm not sure where else to add permissions to allow this to work. Adding sudo chown-socket=djangouser:djangouser in uwsgi.ini didn't work either.
I appreciate the help :)
If you want to run uWSGI as particular user, there are only 2 options:
run uWSGI server directly from this user
run uWSGI as root and add uid and gid options.
You can create a user and set the uid/gid properties in your uwsgi ini file.
[uwsgi]
...
uid=myuser
gid=mygroup
I tested this with uwsgi version 2.0.12-debian and it worked for a simple cgi app using a python3 virtualenv.
http://uwsgi-docs.readthedocs.io/en/latest/Options.html#uid
I am getting a permissions issue when running django in daemon mode. Reading here https://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets I think the solution is to configure the WSGISocketPrefix
The problem is that /var/run/wsgi is no where to be found on my centos server.
The closes thing I can find is: /etc/httpd/run/httpd.pid
How can I find where wsgi is installed?
Or what other value can I set the WSGISocketPrefix equal to?
With Ubuntu 14.0.4 LTS, Django11.1, Python 3.6.1, and mod_wsgi-4.5.15 it works for me as follows:
Apache was showing the following error:
503 Service Unavailable
Apache error log showed the following:
[wsgi:error] [pid 5411] (2)No such file or directory: [client 1.2.3.4:12345] mod_wsgi (pid=5411): Unable to connect to WSGI daemon process 'mywsgi' on '/var/run/apache2/wsgi.5403.0.1.sock' as user with uid=123.
Note that I'm running WSGI as a different user than the default www-data. This is changed with 'user' from WSGIDaemonProcess.
Solution:
At the bottom of /etc/apache2/apache2.conf, add:
WSGISocketPrefix /var/run/apache2/wsgi
After restarting Apache, I can ls -la and see the lock files under /var/run/apache2:
apache2.pid
wsgi.5017.0.1.sock
Sources:
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGISocketPrefix.html?highlight=WSGISocketPrefix%20
https://code.google.com/archive/p/modwsgi/wikis/ConfigurationIssues.wiki#Location_Of_UNIX_Sockets
I'm trying to deploy my Flask app using uWSGI, but I can't seem to do it without sudo.
Here is my start script:
#!/bin/bash
set -v
set -e
cd /var/hpit/hpit_services
/var/hpit/hpit_services/env/bin/uwsgi --http [::]:80 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid
echo server started
Here is what I get in the logs:
*** Starting uWSGI 2.0.9 (64bit) on [Mon Jan 26 15:53:26 2015] ***
compiled with version: 4.8.2 on 23 January 2015 20:35:44
os: Linux-3.18.1-x86_64-linode50 #1 SMP Tue Jan 6 12:14:10 EST 2015
nodename: <<blocked out>>
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /var/hpit/hpit_services
writing pidfile to ../server_pid_file.pid
detected binary path: /var/hpit/hpit_services/env/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 7962
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Permission denied [core/socket.c line 764]
Core/socket.c line 764 has this:
if (bind(serverfd, (struct sockaddr *) &uws_addr, addr_len) != 0) {
if (errno == EADDRINUSE) {
uwsgi_log("probably another instance of uWSGI is running on the same address (%s).\n", socket_name);
}
uwsgi_error("bind()");
uwsgi_nuclear_blast();
return -1;
}
But I don't have instances of uWSGI running. This seems to be a permissions issue. My permissions for /var/hpit, /var/hpit/hpit_services (the location of the app) and /var/hpit/log are bsauer:www-data. My user us bsauer.
If I append sudo -E to the line in my start script that calls the uWSGI binary, it seems to start fine, but I read that a server should not be started as sudo. I inherited this sysadmin role at work and am a little new to all of this.
Here are my hunches/musings:
I know that uWSGI can start as one user and drop into another user role, but I don't really understand this process, so perhaps that's the problem.
uWSGI is trying to access something on the system I'm not aware of
Thanks for your help, I can provide more details if necessary.
EDIT
Oddly, my /var/hpit/log/uwsgi.log file is owned by bsauer:bsauer, not bsauer:www-data or www-data:www-data as I would have expected...
EDIT2
Ok, from looking at http://projects.unbit.it/uwsgi/wiki/Example at the bottom of the page, it looks like the problem is running on port 80. I changed it to 8080, but its still running as bsauer, which I don't think I want.
This is what I came up with as far as I understand it, if anyone wants to put this is clearer sysadmin language I'll be happy to edit.
The solution had nothing to do with the logs after all. The problem was that port 80, the default HTTP port, is protected by the system, and only root can bind to that port. Without sudo, it won't let you bind. Binding to another port, like port 8080, worked fine.
I wanted to bind to port 80 but still run the server as www-data, so I ended up following the very bottom of this page: http://projects.unbit.it/uwsgi/wiki/Example . Basically, the socket to port 80 is shared, and uWSGI can access it first as sudo, and then drop down into www-data to run the server.
I still had to use sudo -E before calling the uWSGI binary, because it needs root permissions to change uWSGI's user and group ID, but it's ok because the end result is the server then runs in the very restricted www-data user.
In the end, my server start line was:
sudo -E /var/hpit/hpit_services/env/bin/uwsgi --shared-socket [::]:80 --http =0 --uid 33 --gid 33 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid
I've been searching throughout this site for a solution but haven't been able to find one. I have a CentOS 6.4 server with Apache 2.2.15, Django 1.6 and mod_wsgi 3.2. I am using Apache to display static files and mod_wsgi to display Django content.
I placed the Django project files in the /srv directory due to this page.
When I run the Django development server, the test page that I wrote up displays properly. However, when I start my Apache server and visit 127.0.0.1, I get a 403 Forbidden error.
django.wsgi (in /srv/mysite)
import os
import sys
envpath = '/usr/lib/python2.6/site-packages'
pwd = os.path.dirname(os.path.abspath(__file__))
os.chdir(pwd)
sys.path = [env] + sys.path
os.environ['PYTHON_EGG_CACHE'] = '/srv/mysite/.python-egg'
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
site.addsitedir(envpath)
from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandlers()
httpd.conf
WSGIScriptAlias / /srv/mysite/django.wsgi
WSGIPythonPath /srv/mysite
<more aliases and tags in order to get the right static files to show>
In the httpd.conf file, the user and group that is listed is the default apache. I ran a ls -l on the /srv directory and its owner and group were listed as root. So, I ran sudo chown -R apache:apache /srv/mysite which changed the directory and all subdirectories to use apache as owner and group.
However, no matter how much I Google or try, I can't get over this 403 error.
EDIT:
I've discovered that when I disable SELinux, and the WSGIPythonPath variable in the http.conf file is django.wsgi, it results in a 500 Internal Server error. However, when I change it to wsgi.py, my website displays properly. I am curious as to why that is.
In any case, since this will be a production machine, I prefer to keep SELinux on and figure out how to get the appropriate permissions figured out.
EDIT 2:
I've edited my django.wsgi file (changed above) ala this link
EDIT 3:
I tried moving my project files into the my /home/ folder. I've been alternating between trying django.wsgi and wsgi.py but still can't get past the 403 Forbidden error. I thought it was originally a permissions issue with the /srv directory but it appears that's not the case...I am trying to figure this out but nothing is working.
EDIT 4:
I decided to just stick the development server for now...but I still need to get this working and I am at the end of my rope. Is there anyone out there that can help me?
SELinux has its own system of granting access. Your process ever has to be granted to access files on filesystem depending on SELinux context. There are some default politics and contexts defined in SELinux those are usefull for default cases of your installation. Just web files are expected to be in '/var/www'. You can mostly check the current context of files or processes using switch '-Z', see
[root#localhost]# ls -Z /var
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 www
Check the context of /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root system_u:object_r:var_t:s0 mysite
The Apache HTTPD server is allowed to access files with SELinux type httpd_sys_content_t byt it is NOT allowed to access files with SELinux type var_t.
1. Change the SELinux type for your directory and check the context
[root#localhost]# chcon -R -t httpd_sys_content_t /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite
Check if your webiste is working right now.
Till now it is not finished yet, while you relabel filesystem to default or if you use a daemon to check or relabel itself, you risk to lose your new labeling.
2. Make the default labaling for your directory
Create the default labeling by 'semange' and apply it on your directory by 'restorecon'
[root#localhost]# semanage fcontext -a -t httpd_sys_content_t /srv/mysite
[root#localhost]# restorecon -v -R /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite
Right now your SELinux labeling is fixed.
Note: It is possible regular expressions to define default context.
Debian: I'm not a Debian user, so the SELinux type can be a bit different, the principle is just the same, check the SELinux type of your apache directory and set it on your directory you want to be accessible from apache.
Read more at RedHat:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
Fedora SELinux documentation:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/