Wednesday, July 20, 2011

Linux File Permissions

Here's an interesting thing I stumbled across. So, lots of companies use Windows boxes for their file server, right? Therefore it stands to reason that you have to get pretty familiar with NTFS and Share permissions if you're a Sys Admin in an environment like this. We won't even talk about the confusion that can arise from discussions about NTFS vs. Share and how they work together. Yikes. As confusing as that can be though, Microsoft hit on something here and provided a level of permission control that is missing or highly obscured on Linux systems.

In Linux, there is no default permissions or user/group inheritance for directories. Say I create a directory under my home folder, set the permissions on that directory to 700, and create a new file in that directory. When all is said and done, the new file will belong to me and my default group, but the permissions on that file will not be 700, but rather will be whatever the results of my umask determine it to be. If I want all subsequent files within that directory to be 700, I have to manually set it to that every time or change the umask, which is a global setting.

Additionally, if I'm trying to write, copy, or move a file into a directory that is not owned by me or a group to which I belong (say /usr/share/apache2), I can obviously sudo that command but then the resulting file is owned by root:root, even if everything else in that directory is owned by apache2 (or httpd depending on your distro). This can be very frustrating behavior, especially if you're not expecting it. Imagine getting phone calls after you performed an upgrade of some software to find out that it's not working because the new files you copied over have the incorrect permissions/user/group.

A little research yielded the information that I could indeed control at least the user or group inheritance using SUID or SGID. I'd read about them in my course of study, but had never actually put them to use. What it boils down to is that in addition to the 3 sets of binary numbers you can use to set permissions on a file (421421421) you can add a 4th set at the beginning that will set the UID, GID, or sticky bit.

For example, let's say we have a directory called webapps that has permissions of rwxr-xr-x, or 755. The owner of that directory is root:tomcat6. You want to keep it so that any time you put a new file or directory in there it is owned by the tomcat6 group. Issuing the following command does that: chmod 2755 webapps. The 2 stands in for the Group, and is essentially applying the same group, tomcat6, to everything within that webapps folder. 755 is simply reiterating the same permissions that already existed. Another way of doing it is to simply use g+s; it does the same thing as the above.

While that solution is fine and dandy if your umask settings automatically give groups the permissions you need, if it is more restrictive this doesn't necessarily resolve matters. Your file belong to the right group, but you still can't do what you need to with it. As far as I have been able to ascertain you would still need to manually change the file permissions on new files if the umask doesn't give you enough.

No comments:

Post a Comment