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');
??
Related
I am developing an application which is having 2 servers. The first one is Web Server, where I save my PHP files and another one is File Server where I am storing all the files uploaded by the user.
I want to assign the write permission to directory at runtime so that I can upload the file and after uploading the file I need to change its permission to its previous state.
When I tried chomod(FILE_PATH, 0755). It shows me an error. Assign write permission as root. I have the administrator level credentials of File Server.
What I want is to "Grant permission 777 to the directory by logging in as root at runtime"
Kindly help if there is any code sample available. Thanks in Advance.
You do NOT want to have your server logging in as root. Let me say that again. You really do NOT want your webserver to be logged on as root. If you did that, anyone that got control of PHP could do anything at all on the server. It is seriously unadvisable.
What you want to do is change the owner of the folder to either be the webserver, or assign it into the same group so that the webserver can happily change your folder options and the like.
You can use sudo chown username somedir to change the owner. This article might also help clear up permissions for you.
Edit: Try this blog post for a fairly good broad-ranging article on linux permissions.
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 want to display image through PHP.
When I put image in /var/www/ directory then it is working fine, I am giving full path.
But when I put image in some other directory (say home) then it is not displaying.
Usually, servers have some kind of sandbox which prevent your code to access files outside of it for security reasons.
I encourage you to put all data you want your server to be able to access inside its folders (/var/www directory or subdirectories of it)
First off, you should really check your error logs as they will probably point you in the right direction.
Without more information, I'd have an educated guess that the Apache user does not have rights to the file and/or the containing directories.
You can change permissions using the chown and chmod commands in a shell.
EDIT: But don't allow access to any dir with sensitive data (e.g. your home directory) to the webserver!
How should I handle image uploading using PHP?
How should I handle the chmod settings?
Example;
I have a dir called /image/ where i want to upload all my images.
Should I set this dir to chmod 777 and leave it like that? Or should i change chmod on that folder via PHP each time I need to upload a image. Is this correct, or should I be doing something else?
As thephpdeveloper mentioned, setting chmod once is enough. All subsequent writes into that directory will not change the directory permissions unless you explicitly chmod it to another permissions somewhere else.
The recommended permissions for directories on a *nix server is 755.
Setting permissions to 777 is not recommended. As mentioned by wic, it gives full permissions to everyone that have access to your server. Which makes it vulnerable if you are on shared hosting or sharing the server with other users.
Also to note is how PHP is run on your server. In fact, if you are running PHP as cgi, example suphp, permissions of 777 for directories are not allowed. Having 777 permissions on the directories your scripts reside in will not run and will instead cause a "500 internal server error" when attempting to execute them.
I recomend chmoding to 755
Only the user running the web server dameon needs permissions to the directory for writing. And you certainly don't want execute permissions on a directory users are uploading to.
Usually, folder settings are set once and that's it. It's rather pointless to keep setting the folder permissions to 777 via PHP, when you have already set it to 777.
No, you dont have to change the permissions on the directory each time. Once set, they are set so to speak.
Using 777 is overkill since it gives full permissions to everyone. Remove the 'x' bit and let apache (or whoever) own the directory. This makes it impossible to list files.
See an example here: http://mattpotts.com/portal/
I put an includeme.htm in each directory on the required path to find the point of failure. It works fine on my local machine (windows) with the same directory structure but fails on my remote (linux) server.
Directory structure:
+-firefli/ drwx--x--x
+-private_html/ drwx------
+-foo/ drwxr-xr-x
+-bar/ drwxr-xr-x
+-portal/ drwxr-wr-w
+-public_html/ drwxr-wr-w
+-foo/ drwxr-wr-w
+-portal/ drwxr-wr-w
The permissions confirm that it's the private_html directory causing the trouble. Hopefully you can see the purpose of the directory structure, I don't know if it's a common way of doing things but it works for me. Well, until now.
I've gone a very long way around asking it but my question is simply this: is there anything wrong with setting private_html to be drwxr-xr-x? Given that I do not want it to be accessible via the web. But the permissions shouldn't do that should they? Because it's apache making the public_html directory accessible via http.
You shouldn't need to block out web users with folder/file permissions on private_html, as it's outside the web root. As you say, web users can only get to stuff in public_html
For future debugging speed, if you have a relative web path you can convert it to a real path using realpath:
$path = realpath('../../private_html');
// $path is now /public_html/foo/private.html or whatever
Well, if you have set up your DocumentRoot correctly to point to public_html, it won't be accessible from the web, no matter what permissions you put on it.
The Private HTMl is not accessible from the web without you putting in a .htaccess file that would redirect it. If you don't know what that means/how to do that, you are safe.
You should be fine setting these permissions to whatever your script needs.
what are the user:group for private_html? The web server needs to be either a member of the group or the owner of the file. In order to read the directory contents the dirctory needs to have the execute permission for the webserver to open it. Essentially they should have the same user:group as public_html. You just want to disallow the write permission. tot he webserver. If you have set your document root to public_html private_html is not accessible via the web no matter what the permissions. Also, i always use realpath on the path arguments to and file operation.