ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
Originally posted by Stranger Correct me if I'm wrong, but I don't think that your web server will override the file permissions.
From "man pure-ftpd":
-R Disallow users (even non-anonymous ones) usage of the CHMOD command. On hosting services, it may prevent newbies from doing mistakes, like setting bad permissions on their home directory. Only root can use CHMOD when this switch is enabled.
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.
Originally posted by Stranger 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.
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...
I had no information about the original poster's setup.
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.
here you can see it only states its at 644 not 777
this is the proftpd config for that user..
User a person
Group a group
MaxClients 3 "The server is full, hosting %m users"
Allow from all
Deny from all
<Limit ROOT_DIR_ALLOW RETR LIST NLST MDTM SIZE STAT CWD XCWD PWD XPWD CDUP XCUP>
<Limit ROOT_DIR_DENY DELE APPE STOR STOU SITE_CHMOD SITE_CHGRP RNFR RNTO MKD XMKD RMD XRMD>
<Limit UPLOAD_DIR_ALLOW LIST NLST STOR STOU APPE RETR RNFR RNTO DELE MKD XMKD RMD XRMD SITE_CHMOD STAT MDTM PWD XPWD SIZE CWD XCWD CDUP XCUP SITE >
<Limit UPLOAD_DIR_DENY SITE_CHGRP >
person and group names are changed for obvious reasons.
* 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.
* 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.
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 _
$ chmod 777 /opt/lampp/htdocs/files/upload
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.
$ chmod 755 /opt/lampp/htdocs/files
What we have here is a failure to communicate. It's all in the details.