I am running RHEL 7 with PHP 5.4, Apache 2, which requires PHP-FPM.
I created a group called WWW and added the Apache user to it. All is working fine for PHP.
I now require to write some files to a directory called "reports".
Reports has the following permissions
drwxrwsr-x. 2 ec2-user www 6 Aug 17 13:23 reports
When I use the following PHP code to write a file to "reports" I get a permissions error
$handle = fopen('text.xls', 'w+');
{
if (!fwrite($handle, $content))
die("cant' write");
}
What are the correct permissions I need to use on the "reports" directory?
In addition to the file permissions mentioned, you also need to make sure you aren't running into a permissions issue with SELinux; it's running by default on RHEL 7.
You can use ls -lZ <location> to see what the current SELinux contexts are for a given file or directory.
By default, /var/www/html has the httpd_sys_content_t context, which will prevent httpd from writing to that directory. In order to allow httpd to write to a directory, you need to tell SELinux to allow it by giving it the httpd_sys_rw_content_t context, which can be done with these commands.
sudo semanage fcontext -a -t httpd_sys_rw_content_t <location>
sudo restorecon -v <location>
Be sure to replace <location> with the actual location of your "reports" directory.
Related
I don't have too much experiences with servers but I've tried to do something ;)
I have my WP webpage on amazon EC2 and
I wanted to edit some settings in php.ini through filezilla (sftp) But I had to set permissions to my user:
sudo chown -R ec2-user:ec2-user /etc
But now I can't even restart apache or set back permissions to root
If i try to do something like this:
sudo chown -R root:root /etc
or
sudo systemctl restart apache2.service
I see this information:
"sudo: /etc/sudo.conf is owned by uid 500, should be 0 sudo: /etc/sudoers is owned by uid 500, should be 0 sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin"
What can I do?
You should never do sudo chown -R ec2-user:ec2-user /etc. You have modified the permission settings of your entire /etc directory.
/etc is a very important folder for your operating system that's why you're getting the error.
launch a new instance and backup your source code from your previous instance and re-upload the code. let me know if you have any issues.
I'm not understanding why you can't modify your php.ini file? You need to ssh into the server and edit the file. If you can't do that, you need to move the file to the ftp folder where it's permissible, modify the file and put the file back to it's original location and restart apache.
Furthermore, I recommend you use Ubuntu for your Wordpress server rather than using Centos or Amazon Flavour of Linux.
log into putty as ec2-user
sudo su
[root#ip-yoursite- home]
now for php 5.0 sudo vim /etc/php.ini
for php 7.0 use sudo vim /etc/php-7.0.ini
press i and now search for upload_max_filesize =100M , post_max_size=100M
(change as per your requirement)
press esc ,now save and exit use this command:wq
restart your apache server
sudo service httpd restart
The short answer is that chown -R is recursive and there are lots of utilities and other files and programs required for various operations, including sudo and su. Root is a special user with uid 0, and that user has greater permissions, and the ability to perform certain operations, that ec2-user cannot. This means that undoing what you have done is not simple or straightforward.
This is why the answers provided so far focus on a reinstallation of the operating system, which is what I would also recommend. It is likely faster.
Another part of this answer is to not try and sftp into the server to change core files. It would require having an sftp login land at the root (or /etc) directory, and that is not a common configuration.
Instead, use sftp or scp to copy changed files to a user directory, and them move them from a command prompt (ssh/bash shell). For simple textfile editing, it is easier to use a command line text editor such as nano which is more user friendly than some of the older editors.
As well, the file itself does not nor should it have its permissions changed, rather, once logged in, use sudo or su to perform the operations. Example:
ssh ec2-user#host.domain.tld
sudo su
nano /etc/php.ini
Imagine that you have a series of boxes, each with two numbers inside. These numbers are mostly 0:0 but could be any whole numbers up to 2^31-2.
The numbers are independent, so 0:0 and 0:42 are both possible. Your -R flag recursively changes all of these numbers in all of the boxes to the same pair.
This loses information. (Without a backup) there is no easy way to know what the numbers in the boxes were before you ran the command.
If you have a matching, (or very similar) server you might be able to restore most of the permissions using rsync, or use a script to record the uid:gid of each file on the working server into a log file and then use that to correct the permissions on the broken server.
ls -n
will show you the numerical values for uid and gid (3rd and 4th column on my linux servers.)
There are two options.
Create a new instance on Amazon. Check the file permissions on the new machine.
cd /etc
ls -lrt
This should give result like this
-rw-r--r-- 1 root root 2064 Nov 24 2006 netscsid.conf
-rw-r--r-- 1 root root 1343 Jan 10 2007 wodim.conf
-rw-r--r-- 1 root root 624 Aug 8 2007 mtools.conf
-rw-r--r-- 1 root root 2570 Aug 5 2010 locale.alias
-rw-r--r-- 1 root root 356 Jan 2 2012 bindresvport.blacklist
-rw-r--r-- 1 root root 349 Jun 26 2012 zsh_command_not_found
Set the same permission on old EC2 instance one by one.
Example
chown -R root:root netscsid.conf
You could create a new setup.
PS: for future, You could use this command for changes in php.ini file rather than changing owner or permission.
sudo vim /etc/php5/apache2/php.ini
No need to change ownership of the folder that contains the php.ini file.
Aim: Grant permission to user 'ec2-user' so that FileZilla can write to /etc folder which contains the php.ini file.
Doing this we can rename the original php.ini file and replace the php.ini file with a modified copy.
Steps:
Login to ec2 instance via 'Putty'
Navigate to the folder that has the php.ini file
example:
cd ../
Use:
ls -l
to list files nd folders with their permissions
Look for the line that shows the folder that contains the php.ini file
somthinng like this:
drwxr-xr-x 80 root root 4096 Jul 11 08:15 etc
Change permissions of this folder:
sudo chmod 777 etc
(NOTE:Change it back to the original permissions later)
Use:
ls -l
to see the change
Restart Apache:
sudo service httpd restart
Now FileZilla will have permission to that folder,
rename the origial php.ini file to revert back in future
replace the php.ini file with a modifided copy
Check ur site(a page which has errors) after a minute, the errors will be displayed.
I have a PHP script application installed on a cloud server.
One of the function is the "PDF Preview", which is currently not working properly.
I contacted the PHP script owner, and he asked me to make sure:
1. dompdf/lib/font/ folder has write permissions (777)
2. the owner of the folder is the Apache user (mostly it is www-data)
For the 1st one, I tried to change the directory permission directly in the FileZilla interface. But it always changes back to 775 after I refresh...
For the 2nd one, I have no idea what it means... I contacted the technical support of my cloud server service. He said it's an App related issue, not server.
Can anyway give me some direction please? Should I use SSH? or anything else?
Really appreciated your help...
Erin
If you have SSH access, it is easier.
1) SSH in and CD into your web directory (likely public_html)
2) run the command chmod -R 777 dompdf/lib/font/
However permission 755 is likely fine...
3) Run ls -l. It will likely look like this:
-rw-r--r-- 1 erin erin 395 Aug 21 2013 index.php
The first 'erin' is the user and the second 'erin' is the group.
There may be other files that have the correct group (such as www or apache). Try and match other files in the public_html directory:
To change the owner: chown apache dompdf/lib/font/
To change the group: chgrp apache dompdf/lib/font/
If you're on shared hosting you might not have access to do this. I'm guessing it's more likely a path or configuration issue than a permissions issue, but give this a shot.
As far as I know you cannot change the owner of a file/directory via FTP. You can via SSH.
The command to change file permissions:
chmod 777 filename.php
To change a directory's permissions:
chmod -R 777 dirname/
To change the owner of a file:
chown www-data filename.php
To change the owner of a directory:
chown -R www-data dirname/
To change the group of a file:
chgrp www-data filename.php
To change the group of a directory:
chgrp -R www-data dirname/
Make sure you are in the file's directory when changing file permissions and ownership with the above commands. Otherwise you'll have to update the path.
If you are updating directories, be sure to be above the directory you wish to update.
Hope this helps.
P. S. To view the current permissions / owner / group of a file or directory, use the ls -la command.
Do not use the database user as the UNIX user. Use www-data.
sudo chown -R www-data:www-data /var/www
There is a difference between the database user and the Apache user. The Apache User is the only one who can actually read the files. The database user is only meant for giving/taking database read/write permissions.
In addition, keep the default permissions from the webapp install. Do not change those, except for the owning user/group. If you are instructed by the webapp, change permissions.
If you are more concerned about security, you could instead run the following commands:
sudo chown -R $USER:www-data /var/www
sudo chmod -R 640 /var/www
This makes the actual files owned by your user, so that only you (and root) can modify them. The reason www-data is referenced is so that Apache can still READ the files, but not actually write to them.
The 640 allows you (the file owner) to read and write, while allowing the www-data group to read files. It also blocks anyone else from possibly reading the file contents.
(The above is only one possible (untested) method. More good ways are available here.)
We have websites running on a linux server with apache httpd and php. On that server a certain directory from a windows server is mounted as let's say /mnt/some_directory/. I can browse this directory with both WinSCP or SSH, using my own user account.
I can also perform the following in SSH:
php -r "print_r(file_get_contents('/mnt/some_directory/file_name.txt'));"
and see contents of that file.
We need to read a file and parse from that directory in order to import it in the database that is used by the website. But when an fopen or a file_get_contents on the website we get a permission denied error.
I have limited access to the web server (and limited knowledge of *nix and apache configuration), but the administrator that is supposed to resolve this apparently is also lacking this knowledge and I need to have this task resolved,that's why I am asking here.
What the admin did was to set the group and ownership of the mounted directory to"apache", which is the user the httpd process is running as. But that didn't help.
As far as I know access to files outside of the webroot is disallowed by default. Would it be sufficient to set a DIRECTORY directive in httpd.conf for /mnt/some_directory/? Or is there anything else that has to be done?
our team had the same issue, my team-mate was able to resolve this by adding context to mount options.
we are using the following format for mounting windows shared folder to linux that apache will be able to access:
mount -v -t cifs <//$hostname/$(windows shared dir)> <mount directory> -o username="<username>",password=<password>,domain=<domain name>,iocharset=utf8,file_mode=0777,dir_mode=0777,context="system_u:object_r:httpd_sys_content_t:s0"
For example:
mount -v -t cifs //192.168.1.19/sample_dir /mnt/mount_dir -o username="admin",password=adminpwd,domain=MIINTER,iocharset=utf8,file_mode=0777,dir_mode=0777,context="system_u:object_r:httpd_sys_content_t:s0"
Link the mounted directory to your www root dir and name the link "share"
ln -s /mnt/some_directory /path/to/your/www/root/directory/share
than try reading the file
php -r "print_r(file_get_contents('/path/to/your/www/root/directory/share/file_name.txt'));"
...or you can allow (if you have enough privileges to edit the webserver's configuration)
<Directory /mnt/somedirectory >
Allow from All
</Directory>
i have seen the same problem with a cifs mount
linux/unix apache that user can have access to the mounted volume, but not apache.
see also this: EnableSendfile off
but when turned off, apache may work slowly,
in .htaccess, only for the cifs mount path, it should work ... .
http://httpd.apache.org/docs/current/en/mod/core.html
best regards
L.Tomas
I have setup apache according to this article
https://help.ubuntu.com/community/ApacheMySQLPHP
and I have created a new site config in /etc/apache2/sites-available/mysite
and changed the document root and directory to :
DocumentRoot /home/gapton/public_html
<Dictory />
..
..
</Directory>
<Directory /home/gapton/public_html/>
...
...
...
...
</Directory>
and I sudo a2dissite default && sudo a2ensite mysite to disable and enable them, restarted apache2 and things are working.
I then setup vsftpd and config the vsftpd.conf file to :
local_enable=YES
write_enable=YES
connect via Notepad++ with the user 'gapton' and I created a file called test.php under home/gapton/public_html. It would not be readable by Apache it seems. I did sudo chmod -R 755 ~/public_html and it would load alright.
However any subsequent files created via vsftpd will not be readable.
Since I have logged in to the only account gapton when connecting via FTP, then any newly created file should be owned by gapton right? What happens when apache tries to access a file/folder location, what credentials does it access it by?
How do I config it so that all files created by gapton can be read by apache? (Also, is it at all advisable?)
Thanks.
I found the problem.
In older version of vsftpd, the umask they apply when writing file was by default 022.
In the current version, such default value has been changed to 077. This mask read 4 write 2 and execute 1 for everyone except the owner.
Changing the umask value in the vsftpd.conf file back to 022 has solved my problem. Hope this help future users of vsftpd facing the same issue.
How do I add SSH keys for 'apache' user in Linux?
BACKGROUND
I am trying to add a service hook to github to notify a URL once I push to my repo. I have the following php page set up:
<?php `git pull origin master`;
However I get the following output:
sh: git: Permission denied
This is because the keys I generated for github access were generated by my 'root' user. However when I exectue a command from php it is the 'apache' user that runs it.
The keys therefore do not correspond and permission is denied to pull.
As I cannot switch user from the terminal to generate keys as 'apache', I am not too sure what to do. Can anyone suggest a solution?
You may have to copy the root generated keys in the .ssh directory of your apache user.
Assuming the homedir of apache is /var/www (check /etc/passwd) and the named key is id_rsa-git :
mkdir -p /var/www/.ssh/
cp /root/.ssh/id_rsa-git /var/www/.ssh/id_rsa
No need to copy the public key.
Note : by default the key used are id_rsa or id_dsa. You may change the name of the copied key to match this.
You may also change ownership of the id_rsa key and .ssh directory:
chown -R apache:apache /var/www/.ssh
chmod 0700 /var/www/.ssh
chmod 0600 /var/www/.ssh/id_rsa
As you are root, you can try it sudo -u apache ssh-keygen -t rsa
Just posting the comment of #KitCarrau, under yvan's answer, that worked for me
sudo -u apache ssh-keygen -t rsa
for debian
sudo -u www-data ssh-keygen -t rsa
after this click Enter twice, to skip passphrase
also, it suggests to create the public/private keys in /var/www/.ssh directory, even if I had my www direcotry in /home/my_user/www, that is fine.
The existing answers are either incomplete or insecure. If you put your .ssh directory into the home directory of the apache user (/var/www) then this will also most likely serve the contents of that directory and thus expose your ssh private key to the public web. To prevent this you'd have to configure apache not to serve the .ssh directory but none of the existing answers explains how to do this.
I'd also argue that it is still dangerous to have your .ssh directory be a subdirectory of your publicly served www-root because even if you add a rule to your apache config, upgrading the server or doing unrelated other configurations might override this rule without you noticing.
So here is an answer that puts the key elsewhere, where it is not served by apache by default. There is not even the need to ever become the www-data user as others are struggling with.
First, find out the home directory of our apache user, for example by looking into /etc/passwd and looking for the www-data user or however the apache user of your distribution is called. The home directory is likely /var/www.
Then run (replacing /var/www with the home directory of the apache user on your setup):
$ mkdir "$HOME/www-data.ssh"
$ ssh-keygen -q -t rsa -f "$HOME/www-data.ssh/id_rsa" -N ""
$ chown -R www-data:www-data "$HOME/www-data.ssh"
$ mkdir /var/www/.ssh
$ cat << END > /var/www/.ssh/config
> Host *
> IdentityFile $HOME/www-data.ssh/id_rsa
> END
$ chown -R www-data:www-data /var/www/.ssh
Now your www-data user will use the ssh key in $HOME/www-data.ssh/id_rsa for all its ssh connections and since your $HOME is probably different from /var/www, that directory will not be served. So even without adding any custom rules to apache, users will be able to see your .ssh/config but they will not be able to access the private key it points to. Nevertheless, your www-data user will know how to do it.
I ran into a similar issue and there is one extra snag. In order to ssh using the apache user you also need to edit the /etc/passwd file so that the directive for apache has a shell defined.
In my case I needed to change
apache:x:48:48:Apache:/var/www:/sbin/nologin
to
apache:x:48:48:Apache:/var/www:/bin/bash
To add to #Vincent, if you have SELinux enabled, you'll have to set the context for the new .ssh folder.
On RHEL, add the following to this file: /etc/selinux/targeted/contexts/files/file_contexts.homedirs
/var/www/[^/]*/.+ system_u:object_r:user_home_t:s0
/var/www/[^/]*/\.ssh(/.*)? system_u:object_r:ssh_home_t:s0
And then run the command
# restorcon -Rv /var/www/
I don't know if this will work on redhat (I assume that is what you're running) however, I was able to su to www-data (the apache user for debian) by executing the following:
sudo su www-data
it actually worked shrugs go figure