I have installed apache 2.2 in centos 6. Everything worked fine when the apache folder was at its default location /var/www/html. Then I configured a Virtual host inside my users home folder. After that apache started showing Forbidden You don't have permission error when I tried to go to localhost or 127.0.0.1 from browser.
this is the code i used in httpd.conf
<VirtualHost *:80>
DocumentRoot "/home/anjan/workspace/mfs"
ServerName anjan-centOS
<Directory "/home/anjan/workspace/mfs">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>
I also disabled SElinux as was mentioned in some articles but in vain. If anyone could help me out it would be much appreciated.
I solved the problem. After meddling with the permission of the system I found out that the user "anjan" who is owner of /home/anjan had read/write/execute permission on /home/anjan but the group "anjan", created when user "anjan" was created didn't have any permission at all.
ls -l /home/
showed
drwx------. 28 anjan anjan 4096 Jan 21 13:19 anjan
so I changed the permission with this command
chmod -R 770 /home/anjan
ls -l /home/
drwxrwx---. 28 anjan anjan 4096 Jan 21 13:19 anjan
i found out under which user my apache is running from this thread. It was running under user "apache"
so I added user "apache" to group "anjan" with this command.
usermod -G anjan,apache apache
after that voila. No more Forbidden error.
P.S. I did everything as the root user.
UPDATE
It seems the provided link is broken now. Heres another one.
Just to be safe(to avoid future broken links), copying the command here. In terminal type -
ps axo user,group,comm | grep apache
This is (for me at least) a doubtful design. It basically means that the Apache user has WRITE access to all that user's files including secrets for example ssh-keys.
Not fun if a cracker attacks apache.
A simple modification would be while running as 'anjan':
chmod -R g-rwx ~ # undo the unsafe -R first
chmod g+rx ~ ~/workspace
chmod -R g+rx ~/workspace/mfs
If apache is a member of the 'anjan' group.
My recommendation is to use ACL:s if the filesystem supports that.
Is SELinux running now ? It should be so and if is still the case that the SELinux policy blocks apache's access to workspace/mfs a number of messages from sealert should be evident in var/log/messages.
This problem is usually fixed with a judicious usage of setsebol.
Disabling SELinux because something isn't working and recommending that method is njaa....
The original problem is that apache runs as itself and because of that is slumped in the other category when calculating permissions.
chmod o+rx ~anjan/ ~anjan/workspace/ ~anjan/workspace/mfs
should be enough.
CentOS 6 is a free (as in free beer) version of RedHat Enterprise Linux and as such RedHat's document https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/ is a necessity.
Related
So I switched to Fedora and wanted to install LAMP on it. So I followed this article: https://computingforgeeks.com/how-to-install-lamp-stack-on-fedora/. Everything has been installed successfully. Afterward, I wanted to change the default root directory. In order to achieve it, I edited /etc/httpd/conf/httpd.conf and have set:
DocumentRoot "/home/muq/Localhost"
User muq
Group muq
<Directory "/home/muq/Localhost">
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
And now I am getting the error: 503 Service Unavailable.
If I change User and Group to default (apache) the error I get is: 403 Forbidden.
Previously I was doing the same thing with Apache on PopOS and it was working fine.
Thank you all in advance!
Did you follow the step in the article which says to set SELinux to permissive? My guess is that you didn't, and that's what's happening: SELinux is preventing user home directory files from being served out by the web server.
You could just follow the advice in the article and just turn it off. But, I strongly recommend that you don't. The thing it's protecting you from here is a reasonable one — a misconfiguration could otherwise very easily expose personal user files to the internet. And here's the key thing: fixing this is really easy! At least as easy as the instructions for disabling SELinux in the article! You just need to do:
sudo chcon -R -t httpd_sys_content_t /home/muq/Localhost
to label that directory as one from which you want to serve httpd content. And that should do it — and still give you all the other protection of SELinux.
(You could also consider a location like /srv/www or /var/www/html as your web root, keeping your home directory out of the whole thing. These are parts of the filesystem designated for that, and to me as a former sysadmin seems cleaner. But the choice is yours.)
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 big doubt how to setup Apache and Pure-FTPd. I don't know how set folder permissions and secure users to not access other folders outsite their home directory.
My scenario:
Apache running defaults (group apache, user apache)
Pure-FTPd using Pure-DB (internal database, not Linux users) - installed using group "ftpusers" and user "ftpuser"
all sites in /sites
I did:
chown apache:apache /sites -R
To create an user on Pure-FTPd:
pure-pw -u myuser -d /sites/onesite -u ftpuser -g ftpusers
pure-pw mkdb
This way I can connect to a FTP account but cannot transfer (permission denied) or delete files.
I can set all /sites to 777 but I know this is not correct. I want to know the correct way, so users can upload/delete files, Apache can read/write files in each website, and if a user upload something to try read outside the /sites directory he gets an error.
Please, help me to secure my webserver using Apache and Pure-DB, plus Linux permissions.
Thank you!
Roger
Not sure if this is correct: I've created the FTP user using "apache:apache"
pure-pw -u myuser -d /sites/onesite -u apache -g apache
pure-pw mkdb
and set:
chmod 770 /sites -R
So everything runs on apache:apache.
Same issue here. I solved it lowering /etc/pure-ftpd/conf/MinUID to my www-data UID number. Though I'd like to know if there is a better solution.
We have a working version of Nagios 3.2.0 running on two other servers but on these new server we installed it using apt-get install but keep getting the following problem.
The permissions and config file is all default from install and everything seems correct when comparing it to the working versions we have of Nagios...
Note: The Nagios website is running but when i click on any option on the left i get this...
Error: Could not read object configuration data!
Verify configuration options using the -v command-line option to check for errors.
Check the Nagios log file for messages relating to startup or status data errors.
Running
sudo /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
Gives:
...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
/var/log/nagios3/nagios.log gives no errors, just a bunch of:
...
[1389054450] Auto-save of retention data completed successfully.
[1389058050] Auto-save of retention data completed successfully.
Not a permission issue either tried changing everything to nagios user and group but no luck:
drwxr-xr-x 4 root root 4096 2013-12-10 16:35 .
drwxr-xr-x 141 root root 12288 2014-01-06 16:27 ..
-rw-r--r-- 1 root root 1905 2011-06-08 01:07 apache2.conf
-rw-r--r-- 1 root root 12218 2011-06-08 01:08 cgi.cfg
-rw-r--r-- 1 root root 2441 2011-06-08 01:08 commands.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 conf.d
-rw-r--r-- 1 root root 26 2013-12-10 16:35 htpasswd.users
-rw-r--r-- 1 root root 43769 2011-06-08 01:08 nagios.cfg
-rw-r----- 1 root nagios 1293 2011-06-08 01:07 resource.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 stylesheets
Changed it back to root.
Stopped Nagios and restarted but still nothing. Please help!
This is a permission issue, webserver user should be able to accees nagios directory structure.
try the following . assuming your web server is not running as the root user.
chgrp -R webserver_user /var/cache/nagiosx/
and also check other nagios directories for correct permissions.
run nagios as daemon
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
Solved it a few days ago. Apache on these servers had been configured long ago to run as a different user, not www-data. This did not solve the problem we had back then so we left it as is and forgot about apache. Now that we have Nagios running on apache this caused the problem.
So it was a permission issue in the end.
Note: When checking if it is a permission issue, don't just check the file and directory permissions, check that what needs access to them is indeed running as that user in its configuration. In this case it was changed in /etc/apache2/envvars
Lesson learnt.
In my case (Nagios 4, Centos 7), I got this error because of selinux permissions (although no traces of any denies were logged to syslog). Simple way to test if the issue is selinux:
Load page, confirm failue.
Run command getenforce, should return Enforcing.
Run command setenforce 0.
Reload page. If it now works, the error is related to selinux permissions.
Optional:
Run command setenforce 1.
Reload page, it should fail again.
There was a SELinux issue, and if you don't like to turn off the security,
you can create a rule just for this situation.
to see the error in human readable format
audit2allow -a -w
have audit2allow create a te allow rule
audit2allow -a -M nagios-www
semange nagios-www.pp
refresh and see it works
The nagios configuration file is referenced in the cgi config file, /etc/nagios3/cgi.cfg. Check if that file contains the line
main_config_file=/etc/nagios3/nagios.cfg
In my case it was permissions on /var/cache/nagios3. You can confirm it by straceing the CGI, i.e. sudo su -s /bin/sh -c 'REQUEST_METHOD=GET strace -fo /tmp/strace.log /usr/lib/cgi-bin/nagios3/status.cgi' www-data.
In my case the web server didn't have permission to access /var/log/nagios/nagios.log.
Had the same problem after an update from Nagios 3.5 to Nagios 4.3 using the RPM packages from EPEL. Solved installing the appropriate package containing the SELinux profile (yum install nagios-selinux). For more details: https://serverfault.com/q/894349/217522
In my case I had to bring broader permissions to objects.cache file. In my case my file is at:
/usr/local/nagios/var/objects.cache
hope this helps
I've set up Symfony2 on the AWS Linux AMI (a free tier micro instance) and set up PHP-FPM and nginx successfully.
My Symfony app works.. until I use the command line to clear the cache. When I do this the /app/logs and app/cache/ folder becomes owned by root and the app can no longer write to it.
I can manually chmod 777 / chown nginx:nginx these files after each cache clear, but there must be a better way?
I've tried using a bash function to su nginx; before it clears the cache, but that doesn't work.
Before cache folder before cache clear:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxrwxrwx 10 nginx nginx 4096 Nov 4 20:39 prod
And after:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxr-xr-x 10 root root 4096 Nov 4 20:39 prod
Is this something I can fix in the app, or is there a way of setting up the permissions so they don't become rooted?
Edit: I should also mention I tried:
sudo chmod +a "nginx allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
But the server doesn't recognise +a.
Also tried using:
setfacl -R -m u:nginx:rwx app/cache app/logs
Which doesn't error, but doesn't fix the issue.
sudo -u nginx php app/console cache:clear
Edit:
Can't accept this answer yet but this worked for me:
So I successfully enabled ACL on my mount following the guide here: http://blog.dsyph3r.com/2011/09/symfony2-using-setfacl-for-cache-and.html
For newbies like, me note the label of the drive is (somewhat strangely) "Label=/" in fstab.
Once that was done I used
setfacl -R -m u:nginx:rwx app/cache app/logs
setfacl -dR -m u:nginx:rwx app/cache app/logs
Now I can clear cache at will it seems.
Original (only use if you cannot or will not enabled ACL):
I followed a help page which got me to set umask(0000); in numerous places, namely the app/app*.phps and the app/console script. This seems to have worked, but I'm not sure of the implications.
Leaving question open for non-umask solutions. Looking into activating ACL on my mount, but new to that and it all seems.. strangely named.