I'm trying to implement php script on server created by someone else.
I try echo shell_exec('ls'); and it works.
var_dump(shell_exec('find / -name "tmp.txt"'));
returns null.
However when I try it in ssh console, the output is correct. What can cause it? What can I check
You're trying to locate something in the root directory, which your web server doesn't have permissions to access (by design) - what you're wanting to do would be a security concern, so my suggestion is to place your work in a folder inside your website, owned by the same user that is allowed to access files on your drive, typically www-data.
Perhaps you don't want to read the root directory of the server itself, and you just want to read a file in the same directory as the website. Switching out the / for a . will access the current directory, not the base directory:
var_dump(shell_exec('find . -name "tmp.txt"'));
Or, you could try an absolute path:
var_dump(shell_exec('find /path/to/files -name "tmp.txt"'));
This is uncommon, but you may need to point to an absolute path for find as well. You can test if you need to do this by running var_dump(shell_exec('find .')); and if it has no output then you will probably have to. Use /usr/bin/find instead if this is the case.
Read more about how to set permissions
Apache: File and Directory Ownership and Permissions for Web Content
A reason for this can be a missing PATH environment variable.
Please check getenv('PATH') and try to use the absolute path to find. A usual place is /usr/bin/find or /bin/find.
var_dump(shell_exec('/usr/bin/find / -name "tmp.txt"'));
Related
I'm having trouble setting up a development server based off of a clone from our production server. We use a CMS and it seems that some of its scripts are having permissions issues. Trying to get to the bottom of it we've set up a PHP script to test the permissions, as well as gotten into the terminal to compare its findings.
Our test script is as below
//try one of the essential folders of the CMS
$path= '[our_base_dir]/html/cms/content'
echo $path.' is'.(!is_writable($path) ? ' NOT' : '').' writable.<br/>';
which prints
[our_base_dir]/html/cms/content is NOT writable.
However, when going into the terminal, I don't see why that would be. Here is the output of that:
$ getfacl content
# file: content
# owner: cchapman
# group: cchapman
user::rwx
user:apache:rw-
group::rwx
mask::rwx
other::r-x
and
$ grep 'cchapman' /etc/group
cms:x:510:cchapman,apache
cchapman:x:512:cms,apache
I believe the apache user is the user that needs to have the write access, and the cms and cchapman users would just be the file owners depending on how they were created. In any case, all three should be able to read and write each other's files based on the group permissions.
This is the same at the file level as well as the directory level. My only thought is that there is something going wrong with how the Apache user is treated at the file level. Could that be it? Or what else would be giving the different access permissions?
I suspect my comment is actually the answer, so I'll post it as one:
By calling is_writable on the path string /html/cms/content, you're checking to see if the absolute path /html/cms/content is writable or not. I believe what you want is:
$path = realpath('./html/cms/content');//note the .
if (is_writable($path))
printf('"%s" is writable', $path);
If the path you're checking really is /html/cms/content, which to me seems odd (I'd expect /var/www/base_dir/html/cms/content or something), then make sure to get the realpath (ie: no symlinks and all that). So always call realpath (as I've done in the snippet above).
Other than that: You have an apache user, that's fine, but are you sure that the script is being executed by that user? www-data and nobody are quite common, too. Check what user is actually running your code, and make sure that user has the appropriate rights, too.
I currently have a php script that is running when a browser browser browses to the webpage. What I'm trying to do is write a text file when the script runs that stores a variable. The owner of the folder is apache, but everyone has read write, strictly for testing purposes. (I thought it might be a permissions issue) SELINUX is enabled on the server, and when I run the script from console it creates the text file just fine, and in the right directory.
file_put_contents("My working file location", $myString);
I'm using this line to try to write and create the text file, I know that my file location works becaus I can run it and create it in offline mode, I.E. running it through console. The problem is that the variable I'm trying to write is populated through HTTP Post, and when I run the script through the browser, or when apache runs the script, it does not write or create the file. What do I need to do to allow access to write/change syntax wise to get this script to write this text file?
Your problem is likely due to apache not having permissions to write to the file location you specified. Go to that directory and check the permissions and group ownership with the ls command:
cd "My working file location"
ls -l .
There are three columns in the output that show the permissions, owner, and group for the directory. Most likely they are owned by root and don't have permissions for apache to write to the directory.
If this is the case, then you will see an error appear in your apache log when it tries to create the file. Try tailing your logs while running the script in your browser:
tail -f /var/log/apache2/error.log
I had the same trouble recently and stumbled upon this question. Unfortunately choppyfireballs the OP said in a comment he found his own solution and just accepted an answer that wasn't helping any of us... Then after a search and a success to make file_put_contents work again I decided to share my solution.
The permissions of my files and directories were ok to accept any writing (make sure your directories are chmod 757 this will give the root and others the grant to write files in the location). If it still doesn't work like it didn't for me, that's because your system is probably SELinux (Security Enhanced Linux) system.
If you want to make sure write setenforce 0 this will turn selinux to permissive mode, run your script again, if it works then it means the problem is well described.
In that case turn selinux on back setenforce 1 and try ls -Zl in the directory where the directory of your project is. this will give you a line like
drwx---r-x. 9 root root system_u:object_r:httpd_sys_content_t:s0 4096 Dec 8 00:25 project
or something different but httpd_sys_content_t if you used chcon to transfer the context from one directory to this one. but if you don't have httpd_sys_content_t it's ok because we need to change the context of that directory anyways.
first you need to accept any public_content_rw_t contexts to write file. Type
setsebool -P httpd_anon_write on
This will set (P)ermanently SELinux boolean httpd_anon_write to true and any context dubbed as public_content_rw_t will have the rights to write any files in their own location.
Now you have to say SELinux that your project directory is public_content_rw_t or you'll still not be able to write files. Type :
semanage fcontext --add --type public_content_rw_t "/project(/.*)?"
and restorecon -RvF /project to tell selinux to apply the above specifications.
Now your directory is public_content_rw_t and you should be able to write files.
I ran into this problem too. In my case, I found that the ownership of the directory was wrong. For a typical Apache installation the directory should be owned by www-data:www-data, not root:root.
Something else to try, for people with a similar question. You might just be making a simple mistake that doesn't require you to mess around with the file permissions—and if you're making this mistake, fixing the file permissions might not help.
Be sure you're using a local, relative file path in file_put_contents().
For example, use:
file_put_contents('short_local_path/my_working_file.txt', $myString);
Not:
file_put_contents('http://example.com/remote_path/my_working_file.txt', $myString);
And not:
file_put_contents('/whole/root/file/path/to/my_working_file.txt', $myString);
Have you tried chmodding the directory to 777?
Try this:
if(file_put_contents('file.txt', 'text')){
die('yes');
} else {
die('no');
}
Might of misspelled something. ^
In my project, I have to upload some video files to a folder which lies outside the root folder. I am using simple php function move_uploaded_file to upload the file. I have tried with the code below.
$source = $_FILES['Filedata']['tmp_name'];
$targetFile = '/usr/local/WowzaMediaServer-3.1.1/content/video.mp4'
move_uploaded_file($source,$targetFile);
But it is not working. Can we done it through move_uploaded_file. if not, suggest a better option to do this.
I have seen some similar question but nothing helps. So any help would be appreciated..
Are you sure you're not in a chroot jail?
If so, your "absolute" path name could be pointing to the wrong place-- somewhere that doesn't exist.
If so, change the path to point to somewhere within the jail.
It may be necessary to mount --bind the directory you want this to go in into some location within the jail. (Note that a symbolic link will not work for getting out of jail.)
More than likely this is a simple permissions issue and quite easy to solve.
Find the user that apache uses. To do this open up your httpd.conf file and look for something like:
User apache
Group apache
Change the ownership of the folder that you're trying to upload to.
chown -R apache.apache /usr/local/WowzaMediaServer-3.1.1/content/
Change the permissions of the folder
chmod -R 775 /usr/local/WowzaMediaServer-3.1.1/content/
And that should be that.
I'm going to assume you're using Apache for the purposes of this answer.
First off, is the file being uploaded ok? One possible reason you might have trouble is that the tmp directory isn't writable by the webserver, or readable come to that. Assuming that's ok then move_uploaded_file should work fine.
Create a folder next to your DOCUMENT_ROOT, let's call it "filestore". Make sure it's writable by www-data or whichever user runs apache. Now, you should be able to move the files into that folder. Note they will be owned by www-data:www-data typically - or whatever user and group your server is set up to run as. The reason I put the "filestore" folder next to the DOCUMENT_ROOT folder is that you can be sure the webserver can read the file path up to DOCUMENT_ROOT. Otherwise you run the risk of a folder part way up the path not being readable, and that'll stop you dead. e.g. if you have /usr/local/media as your target folder and /usr/local isn't readable (and executable) by the webserver, you're toast.
If all this works and you absolutely must have you media elsewhere, you can have the "filestore" folder anywhere so long as the whole path to it is read/executable by the webserver. Check each directory in the path.
If these uploaded files are being downloaded by other users via the web then the "filestore" folder only needs to have permissions of 700 since it's always going to be the web server's user which reads them. If other users need access, typically because other software running as a different user needs to use them then you might need permissions to be 750 to allow group members to read (and execute) the directory. You'll also need to add that other user to the www-data group.
For downloads you will need to write a simple script which dumps the file to the browser after doing some authentication checks. That way, you avoid having the media accessible just via http without having any authentication done first - which could make your service into an attractive place for illegal files (copyright violations being the least concern here).
This is a dangerous approach as it gives root privileges to the apache user, so use with caution.
Add the apache user to the list of sudoers - which will let you execute commands as root in php via system('sudo the_command'). Then move the uploaded file to a temporary location that the apache user can write do (eg. create a 'tmp' directory in the doc root). Then use system("sudo mv \"$source\" \"$destination\""); to move the temporary file to it's final location.
You can find the apache user by executing <?php echo exec('whoami'); ?>. Then add the following entry to sudoers the-apache-user ALL=(ALL) NOPASSWD: ALL. Use visudo to add the sudoer entry.
Example:
$source = $_FILES['Filedata']['tmp_name'];
$targetFile = '/usr/local/WowzaMediaServer-3.1.1/content/video.mp4'
$tempLocation = 'tmp/temp-file.mp4';
move_uploaded_file($source, $tempLocation);
system('sudo mv "' . $tempLocation . '" "' . $targetFile . '"');
Edit: Related question - How to run PHP exec() as root?
Always you face a problem with your code, look at the server log or easier turn on errors display. That said, your problem could be related to upload_tmp_dir setting. Check what a phpinfo() tells about that or look at your php.inifile.
A better solution would be to write the file somewhere where you can write (i.e. under the webroot) and then create a symlink from the media directory to be to where you wrote it.
For example:
Web Root is /var/www/html
You want it at /usr/local/WowzaMediaServer-3.1.1/content/
Create directory /var/www/html/mediaserver/content/
Make permissions on /var/www/html/mediaserver/content/ 777 (so apache can write to it)
Copy files from /usr/local/WowzaMediaServer-3.1.1/content/ to /var/www/html/mediaserver/content/
Delete /usr/local/WowzaMediaServer-3.1.1/content/ (just the "content" directory)
Create symlink from /usr/local/WowzaMediaServer-3.1.1/content/ to /var/www/html/mediaserver/content/
Then you have permissions to read/write, and the media server should too. Only issue would be if the media server is trained not to read symlinks - but you can find that out quickly enough.
I have just created a new folder on my server, and all the right permissions are set, I am sure of it.
The folder is there, but my PHP cant find the actual folder anyways?
Any ideas why?
The only thing I can think of is that my folder has special characters in its name.
I create it with this command:
sudo mkdir "Textiler & Sybehör"
I have lots of other directories with these kind of characters and they work fine.
Just this one seems to not work...
I am stuck!
PHP says cannot find directory...
UPDATE:
In command line tool, I tried moving the dir like this:
mv "Textiler & Sybehör" images/"Textiler & Sybehör"
I get this error:
cannot stat `Textiler & Sybeh\366r': No such file or directory
It is like if the letter "ö" isn't interpreted correctly.
When you make a directory with sudo that means it is created as the super or root user. If your web server is using suexec and running PHP as a normal user, PHP will not be able to access folders and/or files owned by other users.
Check to see if suexec is being used by or on your hosting provider or server.
The other thing is to determine if your folder really needs to be owned by the root user. If not, use the following command to change the owner: sudo chown <regular_user>:<regular_user> where <regular_user> is the account that PHP is running as.
Although it might be because of the characters in the name. What about folder structure? Do you have an .htaccess file with a rewrite base set? Code snippet would be great.
Also may as well check ownership permissions (chown) and then chmod the folder so it's writable.
I have a problem creating an index with Zend_Search_Lucene.
Now, everything works fine on my local machine so I guess there is just an issue with file permissions on the webserver.
Here is how I'm trying to create index in controller:
$index = Zend_Search_Lucene::create('/data/users_index');
Of course the data directory has permissions set to 0777. Here is the directory listing:
public_html
public 0755
css 0755
js 0755
data 0777
Yet I'm getting this error:
Can't create directory '/data/users_index'.
Edit/Update: After further reading and seeing your structure, I'd give it a shot and try using an ABSOLUTE path rather than a relative to ensure its writing to the write location. Sorry I missed that portion earlier. It's obviously not the best practice, but it would atleast narrow down whether or not its a permission/finding issue.
So change it to something like
$index = Zend_Search_Lucene::create('/path/to/public_html/public/data/users_index');
Although, you really should put that outside of the public HTML folder. There's no reason that the public should have access to your Lucene Index Files.
For example, mine are stored here:
'../application/models/lucene/articles/index'
If you are on a Linux/Unix machine, you are going to have to CHMOD the folder or CHOWN/CHGRP so that the web server has write access. If you have access to the server, you could simply run:
chmod -R 770 /path/to/your/data/users_index
If you are not the admin of the server however, you should probably ask the server admin to make sure this is the proper permissions to be applied to this folder, every admin has his/her own quirks about how they want folder permissions setup; what group they should be in; who gets to change it; etc.
If you are on a Windows machine, you are going to have to right click on the folder and grant permissions to the IUSR_XXXXX account and give them read/write access to that folder. (Replace XXX with whatever your machines name is)
$index = Zend_Search_Lucene::create('public/data/users_index');
??