|
|
Posted by farrishj@gmail.com on 05/27/07 04:27
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%2C_read%2C_update_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
Navigation:
[Reply to this message]
|