I have an Ubuntu server running Apache. I have a web application that writes files to a folder. Apache is running as www-data:www-data, so all the files get created using that user and group.
I also have a user shabbyrobe that I use to log in to the box and make non-root changes. If I want to change stuff that has been touched by www-data though, I'm finding myself cracking it and just doing sudo -i, then before I know it I'm doing everything at an elevated privilege level and it really does feel like I shouldn't need to be root at all.
I added shabbyrobe to the www-data group and ran chmod -R 2775 on the folder full of files written by my web application, but new files were still being created as 755, so user shabbyrobe had no access.
Basically, I'm just wondering if it's safe for me to change the umask in /etc/profile from 022 (which seems to be the default) to 002 without compromising the security of my server. I guess I'm just figuring there must be a reason why it's 022 by default, and I don't want to just blithely change it without understanding what that reason is.
Update: in response to Caleb's suggestion, I thought more about it and it doesn't feel like it would be a great idea to set the umask system wide considering it is possible to set it for apache only. So if I change the umask to 002 in /etc/apache2/envvars instead of /etc/profile, what security considerations remain?
Best Answer
Setting the umask to 002 would make all files created also writable by anybody in the same GROUP as the user that wrote the file.
Depending on your system configuration, this could introduce significant security issues. i would not recommend doing this system wide. If you have a particular user or program that would benefit from creating files that are writable by other users in it's group, it would be ok to set this locally to the execution of that program or script, but it would be a Bad Idea™ to make it the default behavior.
Be aware that it is particularly dangerous to allow write access to anything that can be executed by other users because a sneaky change to an executable file might get run unawares by another user and allow malicious code to be executed as their users, compromising their account.