Right, which is always going to be read permissions (chmod=6 for files and chmod=5 for dirs). So how is that different to having the webserver as "others"? The webserver still requires exactly the same permissions (chmod=6 for files and chmod=5 for dirs). Where is the difference?
Actually, Read = 4, for both directories and files. Write = 2, Execute = 1. Add them together to combine permissions. Read+Write = 6. RWX = 7. RX = 5. That sort of thing.
And it's not a matter of permissions for what the webserver can read, it's a matter of what code the webserver can run. Websites aren't just things you read anymore, they're executable code.
By putting your files in the httpd group and having the webserver process in that same group, then you're giving those group permissions to any random shmuck who happens to use your website, which is something you might not want to do.
Consider the case where my users are in group "users", and the webserver is not (say it's httpd/httpd). Now, one of my users loads some PHP or other form of code onto his website directory which, as it turns out, is insecure. So somebody comes along and gets their own process to run on my server using his hole.
What permissions does this process now have? In my scenario, it's running as a process with user/group of httpd. The httpd group is not the users group, and so that process does not get group permissions for the users files. It only gets the world permissions. If those permissions are 644, then yes, there's no difference, but what if some of my users assigned, say, 664 instead? Suddenly we have a bit of a difference.
The difference is conceptual. Untrusted code should not be running as something which will potentially have damaging permissions. The user/group/world difference should be maintained wherever possible.
The webserver is taking input from the entire world and passing that input to untrusted code. If the result of this is that the now running code gets group permissions for darn near *anything* on that server, you're looking at a potential headache situation.
I don't understand just how "others" (world) is actually a "lowest privilege level", as you put it. I don't see any relationship between "others" and any implied privilege level. As far as I was aware, there is no hierarchy in file permissions. There is simply permissions for the user, the group the user is in and everyone else.
All processes have a user and a group. If their user matches the file's user, they get user permissions. If not, then the group is checked for a match. Again, if not, then the world permissions are used. That's the hierarchy aspect of it, a process gets the highest level of permissions that it happens to match. Now, the permissions themselves are separate. I mean, yes, you can assign 604 if you want, letting everybody *except* those in your group read the file, although that would be a bit silly.
Obviously setting files to be writable by the group is exactly the same as setting them to be writable by everyone else.
No. It's not. That's my whole point.
chmod XYZ file.
X = User permissions.
Y = Group permissions.
Z = World permissions.
Group and world are separate. And you want to make sure that running code which is possibly coming *from* the world should never be accessing files based on permissions other than the world.
Say my account name is "mysite.com" and my host puts me into a group called "httpd" (chown=mysite.com:httpd). Let's also say that the webserver username is "httpd". If I chmod a file to "640" that means I can read and write it, other people in the group "httpd" (which includes the webserver) can only read it, right?
Right. So, now how do you differentiate between other users/programs on your server and the rest of world (via the webserver)? What if I have a cron job that runs every day to clean up my site or perform some kind of maintainance? I want it to be able to access some of my files, but not all of them, because I don't know much about this job (say my host provides it, or it's code I haven't examined carefully). It needs write access to some of those files, but I don't want it to actually run as "me" because I don't trust it. So I set it to run as my group instead. Oops, those files are 640, better set them to 660. Oops! Now I've given the entire world (via the webserver) write permissions on my files. Bummer. If my webserver only ran with a different user and group, I could set those files 664 and be perfectly safe while having everything working.
There's three file permission levels for a reason. Bypassing one of them by defining world as equal to group is silly.