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.
Related
I understand this has most likely been answered but for the life of me cannot figure it out.
What is the problem?
I'm running an nginx server and have the user "www-data" own the web server directory and all of it's contents. I run wordpress so it is important that www-data keeps ownership as if it does not, the wordpress UI will not be able to edit files. I also like to use SFTP but have disabled login for any other user besides my own. Currently, when I want to use FTP to edit files, I have to chown the wp-content directory temporarily to my personal user and then re-chown the directory back to the www-data user when finished.
What is the intended outcome?
Ideally, I'd like to configure the file permissions so that I may edit files within this directory without having to chown between users everytime. Is this possible or would I be better off setting my personal user as a root user?
What have you tried?
I've tried chown-ing the directory to a group that both www-data and my user are in. Example being:
chown -R :www-data /path/to/dir/wp-content/*
Where "www-data" is both the name of the web user, AND the name of a group that contains both users: myuser & www-data. Even after doing so, myuser is not able to edit the files within this directory.
If anyone would be kind enough to educate a fool (me) or refer to myself a proper resource, I'd be very grateful! Thanks for your time :)
You should have a user that has associated group, named after that user. So you can do the following:
sudo chgrp -R YOUR_USER_NAME YOUR_FOLDER
this should change owinging group for the data in your folder and that owning group will be your user's group
Then change the privilige for the group using:
chmod -R g+w YOUR_FOLDER
There's already an answer, but I figure I'll give a detailed one anyway, for everyone's sake :)
I'm running an nginx server and have the user "www-data" own the web server directory and all of it's contents
You see where it fails from the beginning, is that any sensitive files can be served by NGINX, unless denied in specifically in configuration, simply because it owns it. It's not good because it won't use chmod permission model as a way to control what NGINX can serve and what it cannot.
There is only one setup that is secure and proper, and I detail it here.
Specifically, each website must have its own PHP-FPM pool, which runs by a website-specific user.
The webserver user (e.g. www-data or nginx) is the member of all website's usergroups, e.g. nginx is member of wordpress usergroup.
This allows to simply have 0750 (dirs) and 0640 (files) permissions, and have no issues at all.
I'm trying to setup a basic Ubuntu 14.04 web server but am having trouble setting file ownership correctly. I want the Apache user (www-data) to have ownership of the web directory (/var/www) and my user to have membership in the apache group. I want both my user and Apache to have the ability to read and write to the /var/www directory.
This is the permission and ownership for the directory I want to share:
drwxrwxr-x 3 www-data www-data 4096 Aug 23 13:39
I've added myself to the www-data group and recursively set permissions on the web directory to 775. Apache is able to read and write but my user, when attempting to add a file over SFTP is getting "permission denied" messages.
What am I doing wrong and should I have ownership setup differently?
Hi, two things to check:
is your user a member of /etc/group:www-data
in /etc/sshd_config, is the user have authorization by pam or AllowGroups+AllowUsers ?
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.
Hope you are good. I have Xammp on fedora and changed owner of opp/lampp/htdoc to root. Why I did so because whenever someone creates new folder through sharing, they don't have permission to dynamically create folder or files or to write images. Then I run command
chmod -R 777 /opt/lampp/htdocs
But when system goes to restart then I again need to run this command. So avoid again and again run this command I changed the owner on "opt/lampp/htdocs" and run
chmod -R 777 /opt/lampp/htdocs
Now, whenever server restarts, assigned permissions don't need to be set again and again. That is resolved.
I have an issue, that old directories can be used to write something. But if any network user creates new directory under htdocs, that new directory needs to be changed the permission for it.
previously created, and can use this one directory to run script to create files
drwxrwxrwx 2 root root 4096 2011-06-15 14:09 aaa
Newly created, cannot be used to run a script to create image or to write anything
drwxr-xr-x 2 root root 4096 2011-06-17 15:17 aaaa
drwxr-xr-x this one is really annoying to me for each newly created folder in htdocs :(
Just to let you know that my htdocs user and rights are:
drwxrwxrwx 101 root root 4096 2011-06-17 15:17 htdocs
Why is it so? Can anybody please help me to figure this problem out? I am waiting for quick response anxiously.
First off, you should investigate what permissions you really need - chmodding everything to 777 is a security risk as it will allow any user to write inside of your web root.
However, to address your actual question of the default permissions when a new folder is created by a user, you want to adjust the default "umask" which determines such things.
This question has some information for changing it for the Apache user (if a "network user" is a user creating new files and directories through the httpd process):
Setting the umask of the Apache user
If you need to adjust it for other users or processes, the solution will be similar.
Good luck!
Edit
Since you're on Fedora, try this: (from the question I linked above)
[root ~]$ echo "umask 002" >> /etc/sysconfig/httpd
[root ~]$ service httpd restart
The first command will add that line to the /etc/sysconfig/httpd which is a permanent configuration file, and the second command will make it active.
You are tackling the problem from the wrong side. Restore your apache configuration to use apache.apache as default user/group, and set your samba server to use those credentials when someone write to your document root.
If you are using nfs or another posix compatible filesystem, use chmod g+s to keep all files readable from your apache server.
Try it:
#umask 000
have a good time!!
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