homepage Welcome to WebmasterWorld Guest from 54.234.60.133
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld

Visit PubCon.com
Home / Forums Index / Hardware and OS Related Technologies / Linux, Unix, and *nix like Operating Systems
Forum Library, Charter, Moderators: bakedjake

Linux, Unix, and *nix like Operating Systems Forum

    
755 Security Holes?
Security issues with 755 permissions on "nobody" owned files.
QLifeTilt




msg:3782403
 4:27 am on Nov 8, 2008 (gmt 0)

In the past I've used 777 directories for scripts that need to make new files, but I've learned of the extremely insecure nature of this.

My question is, are there any security holes or issues with using 755 directories that are owned by "nobody"?

Appreciate any wisdom from you guys. I'm a newb with this subject.

 

phranque




msg:3782447
 9:11 am on Nov 8, 2008 (gmt 0)

welcome to WebmasterWorld [webmasterworld.com], QLifeTilt!

you should think of "nobody" as a complete stranger going through your environment.
think about what you want visible to an unknown/untrusted agent and what you want modifiable or removable by that agent.
i wouldn't give "nobody" ownership or write access to a web script.
if "nobody" happens to be the user name of the server process and it needs write access to something, make sure it is in a safe place.

mcavic




msg:3782870
 8:10 am on Nov 9, 2008 (gmt 0)

It's acceptable for files/directories to be owned by 'nobody' if the Web server needs to write to them, but it should be used sparingly. There could be a number of security holes that would allow users to read/write the files at will.

phranque




msg:3782875
 8:35 am on Nov 9, 2008 (gmt 0)

just a reminder that "nobody" is sometimes also the user name for other server processes such as ftpd.

tangor




msg:3782923
 11:22 am on Nov 9, 2008 (gmt 0)

Secure your folders. Grant permissions as needed. That simple.

wheel




msg:3784125
 1:48 pm on Nov 11, 2008 (gmt 0)

I think (I'm not a linux expert) that the scripts should be owned by the user needing to run them. Thus, if your webserver is executing the script, the webserver user (apache, or whatever the user is on your system) should be the owner of the script and the directory that it needs access to. Then setting permissions to 755 on the directory should let the script do what it needs, but nobody else.

QLifeTilt




msg:3790159
 3:04 am on Nov 20, 2008 (gmt 0)

Hey guys, first I want to thank you for all your suggestions and advice.

In order for our scripts to work, we need to have our directories be nobody:eproxim.

This poses a problem. We need to be able to use regular FTP clients without getting errors. Here's an example of an error we're receiving:

553-Can't open that file: Permission denied 553 Rename/move failure: No such file or directory : /www/psdev/Bankroll-Management-101.html

Is there a way around this? What about 644 permissions instead, would this enable us to access these and still be secure?

QLifeTilt




msg:3790198
 4:44 am on Nov 20, 2008 (gmt 0)

Hey guys, here's a thought... perhaps you could tell me if I'm looking in the right direction.

What if I were to keep the permissions as they are, and use a web-based FTP interface that doesn't use FTP credentials when logging in?

This way the files I'm working with will always belong to nobody. Would I be able to access these files that way though?

ie: [sourceforge.net...]

QLifeTilt




msg:3796086
 4:17 pm on Nov 28, 2008 (gmt 0)

Hey guys, any help would be greatly appreciated. My previous attempts haven't been working so well.

Would this be secure:

Having our directories set to 755 permissions but the specific files that need to be updated via a php script have 777 permissions?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Hardware and OS Related Technologies / Linux, Unix, and *nix like Operating Systems
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved