How to Cope with File Server Permissions Hell - Page 2

 By Charlie Schluting
Page 2 of 2   |  Back to Page 1
Print Article

Alternatively, Marvin could also just be made owner of the file, which also has group-writable permissions. This works well, if the default permissions allow all users to enter directories and list the files. Marvin could easily navigate to the right file, and everything would work. If, however, security measures dictate that users outside the group cannot view the contents of the directories, you have two options. Marvin needs to be given execute and read access on all directories leading to the special file, using extended ACLs. The read access is optional, but without it Marvin won't be able to click through to the right location because he wouldn't see the directory; he would need to use the whole, direct path. Likewise, you could just always set the world executable bit on directories (using the create mask of 2771), and any non-group user would be able to access files within a secure that they have access to, via the full path.

See, it can get horribly complex. Some times the answer is to not store "secure" files on a centralized share at all, if nobody else needs access to them. Other times, a completely new share may be in order if it logically makes sense and wouldn't create two places for people to look when trying to remember where something was supposed to be.

Always the Solution: More Groups

Strange as it may sound, often the best solution is to create a new group. Want a directory in the Sales share that only Bob and Susan have access to? Create it, and set the group to the new Bob&Susan group. You don't need to mess with ACLs or new shares, and groups are managed centrally via LDAP or a text file, so it's easy to see and manage. Adding a new group works in many other examples, and in fact, we cannot think of one where a new wouldn't work.

Not Just Windows Users?

If you have Linux users, your problems just got worse. Often NFS access is allowed to the same files that Samba is also hosting. When this happens, your happy Linux users over NFS generally screw up the permissions. Using Samba, as a Windows or OS X user would, means that the "create mask" rule is enforced on every file write. Users accessing files over NFS must pay attention to their umask, and often it is set incorrectly for group usage.

Setting a umask of 022 means that all files are created as 755, which takes write access away from group members. NFS-based users must set their umask to 002 when accessing group shares, or they must manually chmod every file they create. Also, if each user's primary group is their own private group, in the Linux world, a umask of 002 is not a risk, as home directory files would be group writable, but only to the user that created them.

This subject quickly gets complex, but often the best way to manage is to design a layout that makes intuitive sense for everyone. Then, for exceptions, just create a new group instead of a whole new share; LDAP or Active Directory won't mind large numbers of groups.

This article was originally published on Sep 9, 2009
Get the Latest Scoop with Networking Update Newsletter