Develop Reference

Why am I getting PermissionError [Errno 13] when attempting to write to log in Flask hosted by Apache?

I am running Flask 1.1.4 via Python 3.5.3, hosted via an Apache 2 server on Debian Stretch. I am attempting to log various messages from the program, using the python logging module. This works normally. However, if I restart the Apache server using sudo service apache2 restart, the Flask application errors out with PermissionError: [Errno 13] Permission denied: (log file name). Is this an issue anyone else has run into?

If it is not a permissions issue, this usually happens (happened to me a few times) if you are using a relative path for the log file.
The current working directory for an app running with mod_wsgi is not the directory the the app is in. If you are using a relative path for the log file you can try to use absolute path instead.
More info here: https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#application-working-directory

It turns out that there was a cron process that was editing the ownership of all files in my log folder to root. Once the program was restarted and needed to re-obtain the file reference, it was unable to do so.

"Permission denied" Error in Django Application Deployed on Amazon Elastic Beanstalk

I have deployed a Django project (MyProj) to Amazon beanstalk using the eb CLI. This project is physically located at ~/MyProj. It has an app, named myapp, which needs to execute external python scripts. For this purpose, I have my_launcher.py in ~/MyProj/myapp directory. A code snippet in my_launcher.py is:
import os
import importlib
PROJECTS_DIR = os.path.join(os.path.expanduser(os.environ.get('LOCATION')), 'app/python/')
MY_MODULE = os.path.join(PROJECTS_DIR, 'MyModule/my_script.py')
spec = importlib.util.spec_from_file_location('my_script', My_MODULE)
MyModule = importlib.util.module_from_spec(spec)
spec.loader.exec_module(MyModule)
The reason for using the environment variable LOCATION is to dynamically set the location of external python scripts. I have defined this environment variable and some others through the AWS admin console under the Elastic Beanstalk section. In my example, I have:
LOCATION = '/home/ec2-user/company/'
This script fails at the last line with the error:
PermissionError at /myapp
[Errno 13] Permission denied: '/home/ec2-user/company/app/python/MyModule/my_script.py'
The things I have done so far to no avail:
After reading many online pages (e.g., Django [Errno 13] Permission denied: '/var/www/media/animals/user_uploads'), I thought the issue is Linux permissions on the location where the executable python scripts are (i.e., /home/ec2-user/company/app/python/). For the sake of testing this hypothesis (even though I know it is a bad approach for production), I ran the command sudo chmod -R 777 company while being in /home/ec2-user directory. I redeployed the project and even rebooted the EC2 instance all together. This didn't help.
I moved the company directory inside ~/MyProj/myapp (and updated the environment variable LOCATION on the server) thinking that the wsgi user does not have execution permission on any directory outside ~/MyProj/myapp. This didn't help.
I highly appreciate any help.
By the way, I am using python 3.6 and Django 2.1.7.

Domain not serving wsgi file, but the IP does

I'm trying to deploy a flask application on my droplet, which is running ubuntu, but every time I change my virtual host file to the domain, it just serves the index of /var/www/html and not the wsgi which I specified in the virtual host file. However, if I use my droplet's IP for "ServerName", it works fine.
Any ideas?
Thanks

I had the same problem. Not sure what causes it, but if it's the same one I have you should be able to fix it by disabling the default virtualhost cofiguration.
a2dissite 000-default
service apache2 restart
This should leave just the .conf file necessary for your flask application.
Also you mention a droplet, so you might be following the DigitalOcean Flask tutorial. If this is the case, don't forget to add the .conf extension to the configuration file in /etc/apache2/sites-available

In the server terminal, enter:
sudo nano /etc/apache2/sites-available/FlaskApp.conf
Then replace the raw IP with the domain name.

Proper way to perform privileged tasks from wsgi app

I need to write a small wsgi app for manipulating iptables. I use nginx + uwsgi on Debian with python-iptables package.
uwsgi runs as www-data user by default, so if I try to access iptables from my app I got iptc.ip4tc.IPTCError: can't initialize filter: Permission denied (you must be root).
Is there any workaround to this problem except running the whole wsgi app as root? And what should I do if I want to integrate my app with Django (I definitely don't want run all Django stuff as root)?

You could try to exctract all the functionality which needs superuser privileges into separate script (for example script.py) owned by root (chown root script.py), allow exectution of it (chmod u+x script.py), then set setuid to allow execution rights on that file with root permissions to other users (chmod u+s script.py).
Then you should be able to call that script from your wsgi application using subprocess and www-data privileges.

Running subversion under apache and mod_python

My Apache server runs on some non-default (not-root) account. When it tries to run a python script which in turn executes a subversion check-out command, 'svn checkout' fails with the following error message:
svn: Can't open file '/root/.subversion/servers': Permission denied
At the same time running that python script with subversion checkout command inside from command line under the same user account goes on perfectly well.
Apache server 2.2.6 with mod_python 3.2.8 runs on Fedora Core 6 machine.
Can anybody help me out? Thanks a lot.

It sounds like the environment you apache process is running under is a little unusual. For whatever reason, svn seems to think the user configuration files it needs are in /root. You can avoid having svn use the root versions of the files by specifying on the command line which config directory to use, like so:
svn --config-dir /home/myuser/.subversion checkout http://example.com/path
While not fixing your enviornment, it will at least allow you to have your script run properly...

Try granting the Apache user (the user that the apache service is running under) r+w permissions on that file.

Doesn't Apache's error log give you a clue?
Maybe it has to do with SELinux. Check /var/log/audit/audit.log and adjust your SELinux configuration accordingly, if the audit.log file indicates that it's SELinux which denies Apache access.

The Permission Denied error is showing that the script is running with root credentials, because it's looking in root's home dir for files.
I suggest you change the hook script to something that does:
id > /tmp/id
so that you can check the results of that to make sure what the uid/gid and euid/egid are. You will probably find it's not actually running as the user you think it is.
My first guess, like Troels, was also SELinux, but that would only be my guess if you are absolutely sure the script through Apache is running with exactly the same user/group as your manual test.

Well, thanks to all who answered the question. Anyway, I think I solved the mistery.
SELinux is completely disabled on the machine, so the problem is definitely in 'svn co' not being able to found config_dir for the user account it runs under.
Apache / mod_python doesn't read in shell environment of the user account which apache is running on. Thus for examle no $HOME is seen by mod_python when apache
is running under some real user ( not nobody )
Now 'svn co' has a flag --config-dir which points to configuration directory to read params from. By default it is $HOME/.subversion, i.e. it corresponds to the user account home directory. Apparently when no $HOME exists mod_python goes to root home dir ( /root) and tries to fiddle with .subversion content over there - which is obviously
fails miserably.
putting
SetEnv HOME /home/qa
into the /etc/httpd/conf/httpd.conf doesn't solve the problem because of SetEnv having nothing to do with shell environment - it only sets apache related environment
Likewise PythonOption - sets only mod_python related variables which can be read with req.get_options() after that
Running 'svn co --config-dir /home/ ...' definitely gives a workaround for running from within mod_python, but gets in the way of those who will try to run the script from command line.
So the proposed ( and working) solution is to set HOME environment variable prior to starting appache.
For example in /etc/init.d/httpd script
QAHOME=/home/qa
...
HOME=$QAHOME LANG=$HTTPD_LANG daemon $httpd $OPTIONS

What is happening is apache is being started with the environment variables of root, so it thinks that it should find its config files in /root/. This is NOT the case.
what happens is if you do sudo apache2ctl start, it pulls your $HOME variable from the sudo $HOME=/root/
I have just found a solution to this problem myself (although with mod_perl, but same thing)
run this command (if its apache 1, remove the 2):
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start
When /etc/init.d/apache2 starts apache, it sets all the proper environment variables that apache should be running under.