755 or 775 directories?
 

CuteFTP defaults to 755 directories when you upload, and CuteFTP Pro defaults to 775. Why 775?

depends on your host. some hosts give you a group with your username, others have a shared group across all users (if virtual hosting).

go with 755 if you can, it's the "safer" of the two, but there is a chance it doesn't matter.

Well, I guess there is more than 1 reason to use 775 instead of 755.

Anyway, lets say you have a script which writes a file to a directory. Your FTP is probably running on a different group than your webserver is. If so, it's possible that on some servers the script won't be able to write to the directory if you run it from a browser. Now you could either chmod this directory to 777 to make it writeable or you can 'chown ftpuser:nobody' this directory, if your ftp is running from ftpuser and webserver is nobody, and then chmod it to 775 and it will be writeable without having to chmod it to 777. And 775 is saver than 777.

:-)

I just found a 755 directory and "nobody" has the ability to read and write to the data files inside of it. So is 777 ever necessary? It does not seem necessary for me, anyway.

BTW, how is this possible when the last "5" in 755 means read and execute (no write)?

Can a script read and write a file with "6" permission instead of "7" (with read and write instead of read, write, and execute)?

In other words, what is the execute bit used for?

bump (I edited some posts above).

In that case, the owner would have to be "nobody".

The bits are "owner", "group", "other", so if only the first write bit is set, and nobody can write to it, the owner must be nobody.

Edit: Although, that does seem a bit odd. "Nobody" owns directories on your server?

SpaceAce

Yep, if you can simply do whatever you need to do with the files with 755, then I would really keep 755.

I would avoid 777 as much as possible, and use the chown with 775 option like i gave above instead, if it will work the same as 777.

Yes, if you can simply let the webserver read and write files in / to a 755 directory, then you can probably also chmod the files to 644, and still read from and write to it.

The execute bit is used differently for directories than for files. For files, the execute bit determines who can run it as a program. For directories, it determines who can access that directory.

To answer your question, yes a program can read and write any file with a permission of 0##6 (leading "0" designates Octal Notation. "#" can be any octal number). However, if it was in a directory with permissions that are any even number (which is what happens when the execute bit for "other" is not set to 1), you're going to have problems...

Nope, the owner was not nobody. Any ideas on how that worked?

Since CuteFTP Pro (what I am using now, as CuteFTP is insecure) defaults to settings directories to 775, that is what I am going to keep using.

fiveyes, Thanks. Tell me if I got it right:

- the 'other' execute bit of a directory has to be on for reading and writing in that directory.

- the 'other' execute bit of a file does not matter for reading and writing (only the read/write bits matter).

...so what does an execute have to do with in a file (beside for the x-bit-hack that makes the server parse the html as shtml)?

Server side change on the ftp server

umask 022

What do you mean?

OK, so who was the owner? To write to a file on a *nix system, you need to have write access. If you want to write to a file with only the owner write bit set, you need to either be the owner or root. So, unless your scripts are running as root (DANGER! DANGER!) I don't see how your script could write to a file it doesn't have permission to write to.

If nobody isn't the owner and the owner is the only person with write access...

SpaceAce

SpaceAce,

You forgot about suexec. I know we use it, and I'm guessing a few other hosts do as well. It allows scripts to be ran under a differnent userid than the apache server is run as. It is configurable per virtual host, so we obviously have everyones script run as them (their FTP login). Much more secure, for obvious reasons.

It is very possible suexec is being ran in his case. Try chmod'ing something to 777 and see if you get a 500 server error. Suexec will refuse to run on world writeable directories/files.

So yes, it does give us a bit more of a support problem when people read the directions in script X's readme to chmod stuf 0777. Ugh.

Too bad PHP cannot emulate this behaviour somehow. :( Another reason why PHP is the devil and must die. :)

-Phil

The execute bit for directories allows access to the directory, as well as all sub-directories below it. Without it, you aren't even allowed to chdir into it, much less read or write to any files within. If only the User's execute bit is set, then only that specific User can access it and the same for the Group execute bit. Having the Others execute bit set allows "the world" access to the directory tree. The read bit for a directory determines who may list the contents of it, though without it they can still read a file within it if they know it's name and the permissions on it allows them. The write bit on a directory determines who can alter the contents of a directory, but without it they can still alter a file if the file's permissions allow that. Of course, someone with super-user privileges can access/do anything they feel like!

Correct, reading and writing of files does not depend on the execute bit being set for the file in question. However, if the execute bits for the directory the file is within and ALL of it's parent directories are not set correctly, then you couldn't even determine if it existed or not.

The file could be a CGI program, in which case the execute bit must be set correctly for the server to execute it.

Quite possibly the most useful thread I've seen here today. Thanks! :thumbsup

SpaceAce, Phil21,

I'm not using suexec nor do the scripts have root privileges... I'm going to dive into this and see what I can find out. This is bugging me now.

Ok, here's my full details:

- some scripts are run as "nobody" via cronjobs (set manually)
- some scripts and run as "nobody" via web browsers (set by default).
- all the scripts read and write the same files with 666 permissions (666 = full read and write for all, no execute for anyone)
- the directory containing these files has 775 permissions (775 = full read/write/execute for all except no write for public.)
- all directories above that have 775 permissions also
- all files have user and group "hq"
- all directories have user and group "hq"
- user and group "hq" has no special permissions what-so-ever.

Does that make sense? Is it ok? I guess the directories do not need to have public write ability? If so, then CuteFTP's default 755 (775 = full read/write/execute for all except no write for group or public.) should work just as well as CuteFTP Pro's default 775.

Hello,

Yes, these settings are correct.

A directory should only be chmod'd to 777 if any script has to be able to create files in that directory. If it's chmod'd to 755 all scripts will be able to read/write to existing files in that directory, provided the files are chmod'd to 666 for write access.

Thanks,
Gernot

Wicked. Thanks.