I have a script (Joomla) that creates files and directories on the server. The problem is that it creates them under owner 99 99 (nobody) and after I can't delete or modify them by FTP without the help of the server admin.
I think that is move_uploaded_file function of php.
Is there any solution of this problem by the WHM or by the server admin? Can I modify the default owner in ftp?
What happens is the HTTP server is ran by a user called "nobody", and your FTP user is another one. When the upload occurs, the HTTP server creates the file under its username, and your FTP user has no permission to write (or delete) these files.
The easiest way to fix this (but not really secure) is to add both users in a same group, and change the file permissions to allow users of the same group to read/write on these files.
Your admin should take care of it, but you'll have to call chmod() to change the permissions of your uploaded files.
Explaining it better:
The linux/unix file permissions are composed by permissions of user (u), group (g) and others (o).
I'll only cover 3 types of file permisions here, which are read (r), write (w) and execute (x). So, you end up having something like this:
-rw-rw---x 1 jweyrich staff 12288 Oct 24 00:22 avatar.png
The first rw- is the permission (read/write) of the USER that owns the file (jweyrich).
The second rw- is the permission (read/write) of the GROUP that owns the file (staff).
The --x at the end are the permissions (execute) of the OTHERS users..
Your PHP scripts run as "nobody" user (and by, let's say, "nobody" group), so every file you create from your PHP will be owned by the "nobody" user (and his group). A user can be part of one or more groups.
To solve the permission problem, your FTP user and the "nobody" must be in a common group, let's say the admin put your user in the "nobody".
Once they're in the same group, your PHP script has to give "rw" (read/write) permissions to the "nobody" group members. To do so:
chmod("path_to_your_file", 0770);
The 0770 is equivalent to "u+rwx,g+rwx,o-rwx" , which I explain here:
u+rwx = for user (owner, which is "nobody"), give read/write/execute permissions
u+rwx = for group (which is also "nobody"), give read/write/execute permissions
o-rxw = for others, remove the read/write/execute permissions
After that, your FTP user, which is now part of the "nobody" group, will have read//write access to the uploaded files, and thus can also delete the files. It would look like this:
-rwxrwx--- 1 nobody nobody 12288 Oct 24 00:22 avatar.png
It's not the ideal introduction to unix file permissions, but I hope this helps.
The user that PHP runs under - nobody - is set by the system administrator. There's nothing you can do about that.
You can try chown() to change the file's owner if you know the FTP user's ID. Usually though, you will not be allowed to do this from within PHP.
Depending on the group situation on the server, it could be that if you use chmod to change the file's access rights after the file has been uploaded, the FTP account can access the file:
Try this first:
chmod($uploaded_file, 0660); // owner+group read+write
If that doesn't work, try this:
chmod($uploaded_file, 0666); // global read+write
one of these should make the file usable by the FTP account.
The 0666 is highly discouraged because other users on the server could write into your files, but in some configurations, it's the only way to get going.
Related
I am using Jasperreports for generating the reports. When I am generating the new reports it will be own by root with permission of 644. So other users dont have permission to view this report.I want to change the ownership of the file or change the permission.So everyone can view or download the reports.
I tried below php functions
chmod($item, 0777);
chown($path, 'www-data');
It gives
error: dont have permission to do this
. Because its own by root and current user is www-data.
Anyone please help me,
Actually, based on what you're saying, all users have permissions to view that file. 644 means owner can read and write, and group and others can only read. If your script is getting an error reading that file, it might be because of the permissions of the directories in is path, but not the file itself.
If you could change the owner or permissions of a file owned by root like that, it would subvert the whole concept of unix file permissions. Think about it.
You can always change the user running these reports though, or add logic on the report generation side to move or change the permissions on the file as the user who owns it.
As an aside, chmod 777 is an ugly kludge used only by those who have little knowledge of unix permissions . Professionals don't do it. You should bump your understanding of unix file permissions to the next level:
https://www.tutorialspoint.com/unix/unix-file-permission.htm looks promising.
According to the manual, the owner and the supersuer have the right to do this.
And you only chage the file mod or owner, will not do. You have also to change the path.
chown
Attempts to change the owner of the file filename to user user. Only
the superuser may change the owner of a file.
Note: This function will not work on remote files as the file to be examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or directories being operated upon have the same UID (owner) as the
script that is being executed.
chmod
Attempts to change the mode of the specified file to that given in
mode. Note: The current user is the user under which PHP runs. It is
probably not the same user you use for normal shell or FTP access. The
mode can be changed only by user who owns the file on most systems.
Note: This function will not work on remote files as the file to be
examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed. In addition, you cannot set the
SUID, SGID and sticky bits.
It was a cms and I would like to set all my files on server to -rw-------
This will make my website working as usual? or they will not read each other, for example i have this:
require_once 'include/checksession.php';
First, you need to understand what each "segment" means.
first triad what the owner can do
second triad what the group members can do
third triad what other users can do
Your permission set (-rw-------) only has permissions on the first triad - the owner of the file - which only has read and write permissions.
read The Read permission refers to a user's capability to read the contents of the file.
write The Write permissions refer to a user's capability to write or modify a file or directory.
execute The Execute permission affects a user's capability to execute a file or view the contents of a directory.
Therefore, the owner of the group can read the contents of the file/directory, write to the file/directory, and modify the file/directory.
Under careful file/directory ownership policies, I guess this will be okay - but I wouldn't count on it. If Apache/Nginx/... doesn't have ownership of the file, your application won't work.
This being said, I'd like to raise a few questions;
Why change the permissions of all files/directories on your server?
Why set a global permission rule, and not individual to each file/directory?
What's the end-goal of this?
I'd take some consideration to Jon T's answer
Depends on whether PHP is running as your user or as as something else (Apache, nobody etc)
If it runs as your user (using suexec or something similar), then nothing else needs to read PHP files.
I'd set these to 0600, giving only your user read/write access. Set to 0400 (read-only) for things like config files.
If you have mutiple FTP users accessing your files, then you need to allow group read/write access as well. Permissions then would be 0660.
If PHP is running as another user and it's not in a chroot'd environment, change your webhost.
Also, on a side note, if your CMS requires permissions anywhere of 0777 (I'm looking at you, Joomla), use a different CMS
I'm using a Thumbnail plugin. It store thumbs in a folder on webroot.
but when it's trying to save the thumb, returns "no writable" error. it directory permission is 755.
If i change permission to 777, error disappears. but I read somewhere 777 permission can cause security issues..
What should I do?
you could change the owner (e.g. chown www-data:www-data your/direcotry/path in linux)
chown [OPTIONS] [Owner][:[Group]] FilenameOrFoldername
that the web-server user (the user who executes php scripts) owns the directory, then he has write access and you can leave the rights to 755.
7 5 5 = rwx r-x r-x
read write execute
first digit = owner
second digit = group
third digit = all other users
means that only the owner has write access (he can add files to the directory in this case the www-data user), the group (www-data) has read and execute rights and the rest has read and execute rights too, so there should not be a security risc with 755.
Here you have a tool where you can calculate the right -> chmod number conversion
the rights is written as owner/group/other, i think you can use 775 rights for your logic.
You could store it somewhere that the web server (like apache or nginx) can't access but your web app server (php, java servlet, whatever) can, and make logic for it to grab it from that folder and serve it up as an image. That way, you ensure that any files uploaded by users aren't ever executed.
It would cost more server resources, so that's something you should consider.
If the files are created by your app and there is no way for the user to directly modify them, then there is no problem with giving it write permissions.
I've always used the following codes to create a folder on a Apache server but recently on one of the server I've got permission denied error.
if(!is_dir('img/user/'.$id))
{
mkdir('img/user/'.$id, 0777, true);
chmod('img/user/'.$id, 0777);
}
On internet I found that to upload directory for httpd it needs to have write permissions like this:
drwxrwxrwx 2 user staff 512 Jan 07 12:32 uploads/
Where is this permission set? I do not direct access to the server. Is there any alternatively?
You never want to set permissions to be world writable if you can avoid it, or even readable for that matter. 0770 would be a better option, if still a little broad. The main point is that the folder(s) in question need to be writable by the webserver user. For instance, on many webhosts apache will be run by the user nobody, so a more appropriate permission would look like this:
drwxrwx--- 2 nobody nobody 512 Jan 07 12:32 uploads/
Now, there is a problem if you can't get direct access to set permissions yourself except through PHP, because some web hosts will disallow your ability to run chmod or other permissions or ownership modifications from within PHP. That said, if you're using cPanel (and likely other hosting systems do this as well) you can use the online file manager to accomplish what you want by browsing to the appropriate directory and using change permissions located at the top of the page.
So, ultimately, here's what you need: If you need to be able to create a directory in a particular place, you need to make sure that place is writable by the web server. In your example, that means that you need to set appropriate permissions on img/user first before you attempt to create img/user/$id. That means that img/user either must have permissions of 0770 and must be owned by nobody:nobody (either user or group would work in this context, you don't need both), or it must have permissions of 0777. Then, when you create your specific user directory, you can do it like so:
if(!is_dir('img/user/'.$id))
{
mkdir('img/user/'.$id, 0770, true);
}
... because it will already be owned by the appropriate user and you'll already have write access to it simply because your webserver created it in the first place.
If you can't find a non-PHP way to do it, then you'll have to get your webhost to help.
PHP runs as user: www-data in group: www-data (Ubuntu) or something else depending of the server OS.
You can ask your provider to set the right access on maps / files if you cannot do it yourself by FTP.
I have checked out articles and tutorials.
I don't know what to do about the security of my picture upload-folder.
It is pictures for classifieds which should be uploaded to the folder.
This is what I want:
Anybody may upload images to the folder.
The images will be moved to another folder, by another php-code later on (automatic).
Only I may manually remove them, as well as another php file on the server which automatically empties the folder after x-days.
What should I do here?
The images are uploaded via a php-upload script.
This script checks to see if the extension of the file is actually a valid image-file.
When I try this:
chmod 755 images
the images wont be uploaded.
But like this it works:
chmod 777 images
But 777 is a security risk right?
Please give me detailed information...
The Q is, what to do to solve this problem, not info about what permissions there are etc etc...
Thanks
If you need more info let me know...
You have to make sure the upload folder is owned by apache or whoever user is as which the http server is started.
Alternatively you can use 775 owned by the UID who will be collecting the files and with as gid the group id as which the webserver is started.
There are of course variations on these themes.
As long as the webserver user or webserver group has permission to write in the folder, it will be fine for uploading.
There are all kind of cornercases, but then we'll need more info about your setup.
0 No Permissions (the user(s) cannot
do anything)
1 Execute Only (the user(s) can only
execute the file)
2 Write Only (the user(s) can only
write to the file)
3 Write and Execute Permissions
4 Read Only
5 Read and Execute Permissions
6 Read and Write Permissions
7 Read, Write and Execute Permissions
First number = OWNER
Second number = GROUP
Third number = OTHER USERS
One possibility for why it only works with 777 permissions might be if you are running SELinux. It's possible that it is preventing the write. I would have thought though that it would have prevented it even with the 777 permsissions but I'm no SELinux expert.
Every newbie mix users up. :)
You just have to distinguish OS user and website user.
The latter one has nothing to do with OS permissions.
For the OS users you have given 2 of them:
FTP user, owner of the files, uploaded via FTP
webserver user, owner of the files uploaded via browser.
Site user, who have no direct access to any files at all.
So, in case both these users are the same, you have no worry about.
But usually these are different users. So, one has no access to other's files unless directories has 777 and files 755.
That's why you have to set 777 for directories.
As we have learned above that website users has nothing to do with os permissions, you should not worry about security. 777 is ok.