Hello, I am or have set up a server on a linux box running redhat 9. I have wondering why on FTP/within Linux when I set chmod to 777 it dont read as that.. such as this folder here

http://deathgoth.sytes.net:9000/files/images/chmod.jpg

As you see the CHMOD is set in ftp and in linux as 777 but its only says in this script its set at 644

script here

This script can be found here http://us2.php.net/manual/en/function.fileperms.php


It shows the permissions on a file within the server you are running, in this case Linux..

I have been trying to fix this, I havent come up with a solution so after 2 days I figure I give you guys a shot.

The image on the right shows the permissions of a directory named 'files'.

Your script fetches the permissions of the file '/etc/passwd'.

Some FTP-servers have protection against setting dangerous permissions, like 0777. I know at least Pure-FTPd can do this.

Also, why on Earth would you want to make a directory writeable by world? If I recall correctly, that would give anyone permission to write to or delete the directory itself. If you made it sticky, that would at least allow only the owner of the folder permission to delete it. Correct me if I'm wrong, but I don't think that your web server will override the file permissions.

In any case, this doesn't look like a good idea. You need to have some sort of user authentication to protect your resources. Otherwise you have anarchy.

From "man pure-ftpd":

Hko: I missed the fact that he was using pure-ftpd (with which i'm not familiar), and you posted while I was responding to his original post.

I had no information about the original poster's setup. Since the URL he gave uses port 9000, I wondered if he might have his site hosted on his own computer via DSL or cable and using dynamic DNS through sytes.net (with which I'm not familiar-I guessed and later verified that sytes.net offers dynamic DNS), using port 9000 due to his ISP blocking port 80.

Instead of considering his FTP server, I mentioned his web server. I don't know whether he has overriden permissions with .htaccess or what. If the original poster hasn't considered the ramifications of setting a publicly available resource to 777, what's to say that he hasn't inadvertently left telnet or any other unsecured service running. I don't know the poster's level of competence when it comes to security. I don't know all that much myself. Even if the average user wouldn't know how to delete files on his server through http, someone with more knowledge might know a way or locate a script on his server which would allow him to delete the directory even with overrides in an .htaccess. Such a malicious person might even do worse. I don't know all of the ins and outs of who would have permissions to modify files through http and how, but leaving a directory as 777 doesn't sound wise to me.

Regarding pure-ftpd, I had no way of knowing whether the original poster had used the -R switch to protect himself. If he had discussed it on linuxquestions I missed the discussion. Considering that he might be running his own server, I don't even know if he is running as root to administer his site. I don't know how much he knows about the perils of doing that.

From his screenshot, I considered that he may have somehow verified that he did indeed set the permissions as he intended. In fact, the original post mentions setting permissions in FTP and in Linux which would indicate that DeathGoth tried setting or verified the permissions through a shell or file browser on the server, which would completely bypass pure-ftpd's safety measures.

Of course, changing the permissions of this directory won't address all possible security concerns. We can only patch one hole at a time.

OK, I didn't realize your were writing your post at the same time. Sorry.
BTW, it's not a fact that he using pure-ftpd, but I posted about it to show this could be very well the reason why his script didn't seem to work. And I thought you didn't believe me...
So, neither did I have more info than you.

My mistake. I'm Sorry.

Not a problem. I just wanted to clarify.

Ok sorry for stats problems guys.. here we go.

I am running this set up.

PIII 800
256 megs of PC 133 ram
100 gig HD
32 meg vid card and some lame sound card.

S/W Wise

Redhat 9 as stated in my avator
I am running a program called xampp it can be found here
http://www.apachefriends.org/en/

The things i am running on this server are these.

Apache, MySQL, PHP, Perl, ProFTPD, phpMyAdmin, OpenSSL, Freetype, libjpeg, libpng, gdbm, zlib, expat, ming, Sablotron, libxml2, Webalizer, pdf class, ncurses, mod_perl, FreeTDS, gettext, IMAP C-Client, OpenLDAP (client lib), Turck MMCache, mcrypt, mhash, SQLite, cURL, ZZIPlib, libxslt, phpSQLiteAdmin

I am using Proftpd to run as a server.

THe security issue you guys are fering to, I need to set the folder to 777 cause the script will not work other wise, it is a webscript to allow people to upload files to the server to share with others.

I cant seem to get it going right, I will link you to the file so you can see.

http://deathgoth.sytes.net:9000/files/

As you see the permissions were set to 777, I also set it sticky to that user, and still it says its not set.

http://deathgoth.sytes.net:9000/file.../fileperm1.php

here you can see it only states its at 644 not 777

this is the proftpd config for that user..

person and group names are changed for obvious reasons.

Actually, I just did some tests.

* I logged in to a virtual terminal and logged in as another user.

* I changed the permissions of the home directory to rwx r-x r-x, giving the world permission to read.

* In the user's home directory, I created a directory named 'test' and changed the permissions of 'test' to rwx rwx rwx (777).

* I logged out of the first user's account and logged in to another account and changed to the other user's home directory.

* I tried to rename the direstory 'test', which resulted in a 'permission denied', because the parent directory (the user's home directory) didn't give the world permission to write.

* I also tried to delete the directory, which failed for the same reason.

* I changed directory to 'test' and touched 'test.txt', which created an empty file in the directory, owned by the second user, with permissions r-w r-- r--. (The new file did not inherit the directory's permissions.) Thus, the world can write to the directory and upload porn or illegal stuff to it.

* I switched back to the first user, and I changed the permissions on the user's home directory to 777.

* I switched again to the second user and changed to the first user's home directory.

* I renamed the directory successfully without any permission errors.

Conclusions:

* Setting a directory to 777 poses no risk of alteration to the directory name or location IF the parent directory doesn't give world permission to write.

* Having both the directory and the parent directory set to 777 poses a threat to the name of the directory from anyone.

* Having a directory set to 777 would allow anyone [with sufficient knowledge] to place anything in that directory.

* Of course, having a directory and its parent set to 777 would pose no risk of deletion to a non-empty directory, unless the world had permission to write to every file within the child directory.

I could have told you that.

anyway back to topic.

I'm seeing all sorts of conflicting information here.

The image you referenced in your first post shows the permissions of the directory named /files/.

The script in your first post fetches and reports the permissions of the file /etc/passwd.

The page http://deathgoth.sytes.net:9000/files/ complains about the permissions of the directory /files/upload/.

I don't know which file http://deathgoth.sytes.net:9000/file.../fileperm1.php checks, because I can't see the script.

We're not comparing apples to apples here, and I don't know what to tell you.

Haha! I just wanted to experiment to allay my fears about setting a public resource to 777. I should have checked before spouting nonsense.

http://deathgoth.sytes.net:9000/file.../fileperm1.php

that file i guess checks the permissons of who accesses the file to change whatever, I am not sure.. what the file is there is all the names and pws and such
refering to file /etc/passwd

But http://deathgoth.sytes.net:9000/files/ doesn't need to know about /etc/passwd. It needs the right permissions for /files/upload/.

They used the file /etc/passwd as an example! You need to replace the text /etc/passwd in the script http://deathgoth.sytes.net:9000/file.../fileperm1.php with the name of the file for which you want to check permissions, which would be /files/upload/. (That's what I told you in my first response to you; your image showed one directory and the script checked a different file.)

As I said, the image you showed us in your original post shows us the permissions of the directory /files/. You need to check the permissions for /files/upload/, NOT /files/ and NOT /etc/passwd.

It looks to me as though you chmoded /files/ to 777, when you really need to chmod /files/upload/ to 777.

From your shell prompt _

I would also recommend that /files/ and /files/upload/ shouldn't both have 777, unless Proftpd also needs /files/ to be 777, which would be a poor design (as my experiment in my previous post shows). Perhaps /files/ should be more conservative, say 755.

What we have here is a failure to communicate. It's all in the details.