How to Cope with File Server Permissions Hell
Running a Samba server or NAS appliance consolidates file storage beautifully for centralized backup and management, but one thing has never been easy: file permissions. In this article, we examine why this is often so difficult, and offer some tips on how to ease the pain.
Your new Samba server is humming along nicely, until one day Susan saves a file in the HR Staff directory that Bob wishes to edit. Bob gets a "permission denied" message. This is the most common issue, but the problems only get worse when the security structure requires a complex hierarchical-but-with-a-few-exceptions layout.
Your shared folder structure, or share layout, is extremely important. It is seriously confusing for users when things change, or when bits and pieces are scattered all over between shares due to security requirements. Firstly, we recommend diagramming the directory structure, getting input from as many users as possible. This is easier said than done, since most shares generally move around but never change name. Still, if you have the luxury to completely change everything, do it right the first time.
Initially, you will create groups for user accounts roughly corresponding to the shares created. Say everyone in HR needs access to the HR share, or everyone in sales needs access to the sales share. It's easy at this point, assuming that everything stored in these shares is really for the whole group.
Most importantly, to deal with the Bob and Susan dilemma above, ensure the "create mask = 2775" (or similar) option is set on every share. Setting 2775 means: the setgid bit is set (2) which makes newly created directories have the same group ownership as the parent; owners and group members of the files have full access to them (77); and that everyone else can enter the directories and view the file names (5), which may or may not be desirable. (Need to brush up on Linux and Unix permissions? Get back to the basics with Unix permissions.)
It is easy to give everyone in a group access to a directory, but to allow one new person access to just part of that, is troublesome. The very last thing you want to do is to move the affected directory out of the share. Sure, you can create a new group containing the old one plus the new person for access to the new share, but then people have to remember where this special case lives. It goes something like this: "oh the payroll files all live in the Finance share, but Marvin needed access to the July folder, so that moved out. Go find it in the other share..." As you can see, this quickly gets insane if those types of things are allowed to happen. IT should be able to find a workable solution, enabling the business side to function as smoothly a possible.
One way to allow piecemeal access to specific files or directories, is with extended ACLs. You can specify, for example, that Marvin gets access to a particular file, in addition to the normal user/group combination that exists on it. See the getfacl and setfacl manual pages for information on how to configure extended access control lists.
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.