This is a discussion on PHP chmod Newbie Question within the PHP Language forums, part of the PHP Programming Forums category; Hi, the PHP manual says that there are three separate sets of users that the chmod funtion recognizes: the owner ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Hi, the PHP manual says that there are three separate sets of users
that the chmod funtion recognizes: the owner of the file, the group that the owner is in, and everyone else. How does the server keep track of who created the file? I don't see how this could be managed with cookies or by tracking ip addresses. Also, how do I create user groups for chmod to recognize? The project I am working on involves users uploading files to a single directory on the server. The MySQL database keeps track of who created which file (based on the file's name and the user's username) and only allows the users to view files they created. My problem is that my php script only lists the user's files, but when they are viewing a file, the user may easily change the url to the name of a file they are not authorized to view, and then successfully view it. I have no idea how to secure this system, other than using the chmod function. -Karl |
|
|||
|
On May 25, 2:36 pm, Karl Cox <kcox7...@yahoo.com> wrote:
> Hi, the PHP manual says that there are three separate sets of users > that the chmod funtion recognizes: the owner of the file, the group > that the owner is in, and everyone else. How does the server keep > track of who created the file? I don't see how this could be managed > with cookies or by tracking ip addresses. > > Also, how do I create user groups for chmod to recognize? > > The project I am working on involves users uploading files to a single > directory on the server. The MySQL database keeps track of who > created which file (based on the file's name and the user's username) > and only allows the users to view files they created. My problem is > that my php script only lists the user's files, but when they are > viewing a file, the user may easily change the url to the name of a > file they are not authorized to view, and then successfully view it. > I have no idea how to secure this system, other than using the chmod > function. > > -Karl CHMOD (change-mode) is for UNIX based servers, and the PHP chmod() function is basically for when you are writing scripts for deployment on them. UNIX (and others based off it, like Linux) have a built-in authorization system to control who has access to each file. These users are not users who would log into your website, but rather users who would log directly into your server (by FTP, SSH/telnet, etc) and for scripts to run as. PHP runs as a user (or as you if you are using the CGI build), and you log in as yourself when you connect through FTP. What chmod() does on these servers is change what access (read, write, execute) each user has as they are related to the file (owner, group, anyone). This would be used in PHP to programmatically change who can do what to files, such as setting an image file to only be able to be edited or removed (write) by the PHP script, and only read by the UNIX group (UNIX users are assigned to groups so you can allow file access based on groups) while anyone who is not the same user and is not in the same user group as the file owner (anyone else) cannot have any access to the file. This is mostly for controlling basic file security. So chmod() will not help you in your case, as the users you are dealing with are not UNIX users but website users. It's completely unrelated. You wouldn't want to make those website users UNIX users anyway since that would be so they can log into the server and access files by FTP or whatever, not using your website. You have to write your own code to handle who can access what file. Here's a basic idea, which would be part of the file view page: -Save images into a folder that no one can access on the internet, you can use those UNIX file access things to deny access to anyone other than the file owner (which will be whatever PHP runs as) -The file view page is a .php script that takes an URL variable to decide what image to display, such as: viewimage.php?image=sharks.gif -The PHP script in that page checks the database to see if the currently logged in user (use whatever code you use to see if they are logged in, such as checking the cookie or session) has access to that file -If they don't have access, continue the script with a different file name. You can do something like $_GET['image'] = 'nogo.gif'; -Use code to make sure the image file name does not contain slashes or stuff that they could use to access a file that you don't intend them to. You can do this earlier in the script if you prefer. -Use the PHP header() function to send the Content-type header to the browser (to tell it that this is an image and what type of image it is). Use code to find the appropriate Content-type header to send based on the file extension -Use readfile() to feed out the image to the browser. If your inaccessible directory is "images", it might look like: readfile( 'images/'.$_GET['image'] ); Make sure to write secure code! If you're not careful, this will be open to file system hacking and SQL injection at the same time. Make sure to mysql_real_escape_string() the URL variable as well as make sure it's clean for the directory (no slashes or anything). You can use this same technique for any file type. Just make sure you are careful with the file extensions, if you are using an upload script and they upload a .php file instead of an image, it might be possible for them to run that PHP file instead of downloading it (by going directly to it). That nogo.gif image I put in there would be just an image that has text that says, "You don't have access to this image!" to be displayed instead when appropriate. -Mike PII |
|
|||
|
On May 25, 1:36 pm, Karl Cox <kcox7...@yahoo.com> wrote:
> Hi, the PHP manual says that there are three separate sets of users > that the chmod funtion recognizes: the owner of the file, the group > that the owner is in, and everyone else. How does the server keep > track of who created the file? I don't see how this could be managed > with cookies or by tracking ip addresses. > > Also, how do I create user groups for chmod to recognize? > > The project I am working on involves users uploading files to a single > directory on the server. The MySQL database keeps track of who > created which file (based on the file's name and the user's username) > and only allows the users to view files they created. My problem is > that my php script only lists the user's files, but when they are > viewing a file, the user may easily change the url to the name of a > file they are not authorized to view, and then successfully view it. > I have no idea how to secure this system, other than using the chmod > function. > > -Karl What you want to do is put the files into your database and use content-headers to deliver the files to the requesting party. This way, you use your users extended read/write/executable permissions and privileges to grant and deny access and also writability (who can "save" the file?). You do this by putting them in groups and set 1) user, 2) group, and 3) "other" (everyone not in user or group permission zones) permissions. These are the three permission paradigms you mentioned, which is how CHMOD is implemented in *nix systems, and obscured a bit in windows. look at this one ---> http://en.wikipedia.org/wiki/Create%...ate_and_delete http://en.wikipedia.org/wiki/File_system_permissions http://en.wikipedia.org/wiki/Chmod When you store the file, base64 the actual file contents before you insert the string. This is recommended for a few reasons, the least being it uses a very limited symbol set, unlike unicode, which can pose some translation issues. When you deliver the content to the person receiving it, you should also be able to describe it using content-disposition and some other flavors. Consider: > It is desirable to keep the set of possible disposition types small > and well defined, to avoid needless complexity. Even so, evolving > usage will likely require the definition of additional disposition > types or parameters, so the set of disposition values is extensible; > see below. More about content-dispostion - http://www.ietf.org/rfc/rfc2183.txt |