I have a few different servers, and on some servers, I can chmod the public_html folder to 777 permissions without problems - but on other servers, I get error messages. When trying to access the domain I get an Internal Server Error, and in my cpanel error_log on one server I get messages like the following:
Fri Oct 08 09:55:39 2010] [error] [client x.x.x.x] SoftException in Application.cpp:601: Directory "/home/managedi/public_html" is writeable by group
The reason I need to temporarily change the public_html permissions to 777 is so that a php script that executes the shell unzip command will work properly, and be able to extract files when accessed via URL.
Is there some server setting that causes 777 permissions for public_html to give an Internal Server Error? How can I get rid of this error while still changing the permissions for public_html?
Turns out this is because some servers have SuPHP enabled, while other servers do not. SuPHP can be enabled or disabled in cPanel WHM under: Main >> Service Configuration >> Apache Configuration >> PHP and SuExec Configuration
If SuPHP is disabled, then PHP runs as an Apache Module and executes as the user/group of the webserver, which is usually "nobody".
Related
I have a Laravel project on my CentOS7 server which sits on the folder "/var/www/html/myProject".
I have changed my document root in /etc/httpd/conf/httpd.conf to "/var/www/html/myProject/public" both in "DocumentRoot" and in the directory configure so when i enter the IP in the browser it will automatically show the project.
When i try to do so and access my IP through the browser i am greeted with the messages:
Forbidden
You don't have permission to access /form on this server.
Server unable to read htaccess file, denying access to be safe
After further examination i have found out that in my /var/log/httpd/error_log i get the following error after every access attempt:
[Thu May 10 19:39:33.683522 2018] [core:crit] [pid 1994] (13)Permission denied: [client 79.182.62.1:51091] AH00529: /var/www/html/myProject/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/html/myProject/' is executable
That was very odd to me since the path is supposed to be /var/www/html/myProject/public, but the "public" is missing.
I have restarted my apache several times, and changed the DocumentRoot path to a fictional path just to check if it updates and it is.
Could it maybe be something in the .htaccess file? although i didn't change the file, i left it as Laravel created it.
Check the permissions on /var/www/html/myProject files & directories. Based on the error you pasted it seems apache is attempting to read in data from your myProject directory as directed by the .htaccess file. This is normal operation.
Figure out what user/group your apache is running is. Then remember that your files have to be readable that user and all parent directories have to be accessible (hint: execute bit) for that user.
Finally check the bootstrap/cache and storage laravel directories (& subdirectories) are writeable by the apache user.
For my desktop machine, I'd like to be able to access files in my home directory in a browser.
I have set the Apache DocumentRoot to my home, but I get logically a forbidden page. I tried to add www-data user in my group, with the same result.
I would not prefer give full access to any user in my home.
So how should I proceed to let apache read my home dir?
$ ls -la /home | grep gael
drwxr-xr-x 44 gael gael 4096 mars 17 22:30 gael
$ groups www-data;
www-data : www-data gael
The error log:
[Tue Mar 17 22:43:06.592819 2015] [authz_core:error][pid 4572] [client 127.0.0.1:59677]
AH01630: client denied by server configuration: /home/gael/
apache conf:
<VirtualHost *:80>
DocumentRoot /home/gael/
</VirtualHost>
make sure that the user running the webserver has full read permissions to all files they need to see. they will also require execute permissions for any directory they need to traverse into.
so it seems that you have added the www-data user to your own group, which should fulfill the above.
be aware, that a new group-membership does not take effect immediately: interactive users need to login again, a daemon needs to be restarted (thus: restart apache). the w32 way (just reboot) will also work.
btw, exposing your home via a webserver seems like a bad idea: anybody who can access the webserver (usually anybody on the same net) will be able to see your home-directory. make sure that you add extra security (password protection, encryption,...).
btw, did you know that the ~/public_html directory is traditionally exported by your web-browser as ~<user> (so if your login name is "gael" you can access this directory via http://localhost/~gael/). if the directory does not exist, just create it and make sure that you set its group to www-data. this is a much more secure way to share some data via the web.
I have a folder in ~/Documents/WebD/ named Tarea which have a public_html folder inside, to access it I have tried creating a virtual host in a thousand ways but it didn't work, now I'm trying to get there creating a Symlink from tarea to /var/www/html/tarea, and accessing via localhost/tarea/public_html but y get
Forbidden
You don't have permission to access /tarea on this server.
Apache/2.2.15 (CentOS) Server at localhost Port 80
I tried a lot of different ways named on forums, changing httpd.conf, give permissions to apache, etc, but non of them worked
Any suggestion?
It could be SELinux preventing Apache from accessing those files. I would try switching SELinux into permissive mode and seeing if your permissions open up. You can read more about SELinux and Apache here.
To put SELinux into permissive mode, do:
echo 0 > /selinux/enforce
To put SELinux back into enforcing mode, do:
echo 1 > /selinux/enforce
Hope you have already checked Persmissions for /tarea folder. The User which is running the Apache server should have read/write permissions on the specific directories.
I've got a LAMP webserver running my homepage (index.html in var/www/). I'd like to know in general how to set my file permissions so that browsers can't access anything besides the html/php files I want to show. Right now I've sort of accidentally chmodded everything to 777. I understand that .htaccess only protects the www folder and inwards... How can I set my permissions so that I have an svn folder that svn can still access but browsers can't?
In security you should follow the paradigm of "Least Privilege Access". It is best to do a chmod 500 -R /var/www chown www-data -R /var/www. This is assuming that your php code is running as www-data, you could run a <?php system('whoami')?> to verify your user account.
A chmod 500 gives the web root read and execute privileges. Write privileges is very dangerous as this is vital for defacing your site. The last number should always be zero, this is global privileges and you don't want any other account/process accessing your webroot.
I have a web application (bugzilla) in apache that needs to use sendmail.cf . When it tries to use sendmail I get the error:
/etc/mail/sendmail.cf: line 0: cannot open: Permission denied
the web application is in group "apache"
Permissions for sendmail look like:
-rw-r--r-- 1 root root 58624 2008-03-29 05:27 sendmail.cf
What do the permissions for sendmail.cf have to look like in order to be accessed by apache but still be secure enough to lock out everyone else.
I have this issue in a Centos 7 and the answer was here:
http://www.mysysadmintips.com/linux/servers/591-sendmail-won-t-send-emails-on-centos-7-permission-denied
Quick 'sestatus' check revealed that the issue was caused by SELinux.
Running: getsebool httpd_can_sendmail returns off, which means that
Apache (httpd) doesn't have permission to send emails.
The issue was resolved by running: setsebool -P httpd_can_sendmail on
You should have a different .cf file for local submissions, usually called (something like) submit.cf - this will have a slightly different batch of settings specifically for SENDING mail (whereas sendmail.cf will be the part for RECEIVING mail). The submit.cf is safe to be globally readable, because (in theory) all processes on the box should be trusted to send email.
Set the user as root and the group as apache: chown root:apache sendmail.cf