This is an basic question but I'm having trouble googling the right answer. I'm migrating from netware to samba domain controllers and attempting to get file permissions to function as I'm used to (or close to it). Using netware I can grant a user/group write permissions to a subfolder and netware will allow browsing to that subfolder without granting read or write to any folders/files in the parent folder. How do I set this up with Samba/Linux? The closest I've been able to get using ACL and Windows advanced security is adding a user to the parent with Traverse and List allowed, this will automatically enable Read (I guess do to POSIX ACL limitations), then granting Read/Write to the subdir. This unfortunately allows the user to read all the files under the parent. He can't save or delete them, but I don't want him reading them at all.

If someone could please let me know how to do this right, or describe a different approach to directory structure I would appreciate it. I'm trying to avoid making 100 different Samba shares and using 36 drive letters.

Delete My account

The crux here is that you want different permissions on directories from the files that are in them.

I believe that if you remove the world, i.e. "other", "r" & "w" file permissions from the files in question, while leaving the "r" permission on the directories containing them, you will accomplish your goal:
W/ a result like this:

I have a folder:

Secr
|_Prj
|_Notes

Group Secr has rw to Secr and subfolders/files.

User Jim has r to folder Secr ONLY, not subfiles, has r/w to Prj.

This works to get Jim into the Prj folder and keeps him out of the Notes folder. The Problem I'm having is when a user creates a new subfolder under Secr, user Jim then has read access since he has read access to the parent. If I configure samba so new files don't inherit parent permissions, then Jim cannot see new files created under he Prj folder.

How do I set this up as I need it? Do I need to use a different directory structure? I'm afraid I'm going to end up required to give a user access to a folder nested 12 directories under the root folder and this is going to make a enormous mess. I'm sure this is a common issue so how are people dealing with this?

If a user or group has only x access to a directory, they can traverse it, not read the file listing or create new files.
Of course, if they have r and/or w access to any files in that directory, and they know the file name, they can read and/or write those files (and those only).

If a directory has the setgid bit (g+s) set, for example mode 02771 or drwxrws--x, then any files and subdirectories created in that directory will be owned by the same group as the directory, regardless of the creator user.

Can you tell us more about the user hierarchy a bit more? Which users need what access to a directory? The example needs to be complicated enough to describe your user hierarchy.

Nominal Animal

1 members found this post helpful.

Delete My account

The Traverse/Execute bit is interesting though it has issues. The user can't see the folder and therefore cannot navigate to get to the subfolder through the directory tree, if they type it in manually they get no access. In the above tree this allows me to completely block access to everything under Secr and by putting r/w on Prj, if I make a shortcut to Prj then Jim can then navigate the directory tree to get to the folder he needs. This might be sort of a clumsy last restort method.

I have several samba shares divided by task. Acctg, Cad, Secr, etc. This is fine 96% of the time but invariably some project manager needs to get into a single folder in Acctg. The PM isn't in the Acctg group so I have to add him in personally. Using Netware I'm able to click the folder (or file), give him r/w access, and everything else takes care of itself. Only the directory tree necessary for him to navigate to the folder is exposed and he has access to nothing else. This is what I'm used to and am trying to emulate. Alternately I'm going to need to come up with a different directory or share structure to make this versatility possible, I'm just not sure what that would look like.

Okay, that sounds quite sane and achievable. First, enable POSIX ACLs so you can add the 4% of exceptions by hand. Then, assume you have this directory structure:
Setup Samba to set read and write user and group access but no access to others for newly created files, i.e. umask 007.
The root /shares/ directory is not absolutely required, but you'll most likely have something like it. (And if you have users that should not have any access to any of those folders, just exclude them from the shareusers group.)
Note the s in the group mode; the intention here is for the group owner to be always inherited from the directory.

The exceptions will be handled purely using POSIX ACLs. Assume there is a directory
to which user bob needs access, but without any access to other Acctg or Janet files or folders. And of course, bob is not a member of group acctg.

First, you'll add u:bob:rwx or u:bob:r-x to /shares/Acctg/Janet/ProjectX/ to give bob the rights he happens to need. (Or, in other words, an additional access control for user bob which allows him read, maybe write, and traverse rights.)
Then, you'll also add u:bob:r-x to all directories up to but not including /shares/ -- in this case, to directories /shares/Acctg/Janet/ and /shares/Acctg/.

Because all files and subdirectories are created without any other access, and bob is not a member of the acctg group, he cannot read or access any of the files and other directories in /shares/Acctg/ or /shares/Acctg/Janet/ at all. (He can see the file and directory names in those two directories, but not otherwise access them in any way.)

If you're a command-line person, you can very easily write a script to do this automatically using setfacl, if your directory structure is this simple. An example interface would be e.g. allow-user-exception bob rwx /shares/Acctg/Janet/ProjectX/. The script first adds the specified exception to the specified directory, then traverses upwards adding traverse and read rights to the directories for the user, until it gets to a directory where the user already has traverse and read rights.

It's been a while since I've last managed a Samba server, so I'm not sure which GUI tools or Samba config utilities are appropriate for this, sorry. I'm sure there are, though.

Cheers,

Nominal Animal

1 members found this post helpful.

Thanks for the post. I've been able to get bob access to what he needs like this.

The samba share:
By adding bob to the valid users this gets him through Samba security.

According to the MAN all the "Force Modes" are negated by using "Inherit Permissions", however I could've swore I was having some issue with users being able to access each other's files before I added these.

I installed ACLs and add x for bob to the /home/Secr folder. This allows bob to get through it but not browse the root share or read any files directly under it.

Then using Windows Security Properties I can add Bob to each folder in the tree so he can access /Secr/Prj/33x/xls. I then give him r/w on the XLS folder and he can write to the files under there. This is a little tedious adding him to every folder but it gets him through. One significant problem I'm having though is because I'm using Inherit any new folders made under Prj have bob's Traverse permission. I don't want this obviously, but if I remove inherit then bob doesn't have the ability to see new files created under the XLS folder. Hmm. Lemme try some other things and get back. I can't have him added to new folders under the PRJ directory. Any ideas let me know.

Fooshnik, I thought of many ways to do this, but all seem to have their downsides. What do you think of the following?

Use inherit=no, and a separate inheritor helper running on the server.

You'll need the inotify or inotify-tools package depending on your distribution.
inotify can be used to efficiently detect the creation, deletion, renaming and moving of files and directories. In your case, you'd have an inheritor script regenerating the extra ACLs when files or directories are created or moved, based on the extra ACLs in the (destination) parent directory.

It works almost exactly like Samba inherit=yes, except with transformation logic:

• If the parent directory has --x for a user, subdirectories inherit --x, files nothing.
• If the parent directory has r-x for a user, subdirectories inherit r-x and files r--.
• If the parent directory has rwx for a user, subdirectories inherit rwx and files r--.

In the Samba configuration, you could allow all users access to the share, but with hide unreadable = true. The share root directory access permissions will reject all access by the unwanted users.

To add the exceptions, you simply open the Security Properties dialog in Windows, add the user to the destination folder with either r-x or rwx (cannot remember what they are in Windows-speak).

You'll also need a periodic script which does the inheritance for the entire directory tree.

Personally, I'd add a marker file, say Up-to-date, and an inotify script watching it.
When you do one or more of those exceptions (or somebody complains of an access problem), you remove the marker file.
The inotify watcher script then runs the periodic sweep twice for the entire share, and then regenerates the marker file.

Heh, you's only need to remove the marker file, and wait for it to reappear; then tell the user to retry.

Security-wise there is no problem: the inotify inheritor script is not atomic (it does not block the event, only notes it happened),
but since the extra ACLs just grant access, an occasional delay is not a problem.

If you want, I can start a new thread with an example implementation; it might be useful for other Samba admins, too.

Nominal Animal

I don't know whether it may apply to your setup: it's possible to mount a subdirectory with the bind option to mount to an upper directory and skipping this way the directories on the way to it. For backup purpose it would still be sufficient to backup the original directory tree, but some users can access subdirectories by accessing another share which points to the additional mount point.

Thanks for the help. This seems to be a bit more refined then my last attempt. It allows users to browse to the folder or file they have access to, write to the destination folder/file, permissions propagate in the rw folder but not the read only folders. This hasn't been tested enough but so far it seems to work as I wanted.

Scenario:

Samba share called "Secr" located on the server at /home/Secr. Share is mapped to the S:\ drive on the workstation. Owner and group Secr have rwx, Everyone has zero permissions. User Bob is not a member of the Secr group but needs rw access to the directory S:\Prj\32x\XLS (would show using windows UNC at \\server\Secr\Prj\32x\XLS). This is what I've done here:

1. Edit the smb.conf so the share looks like this:

2. On the file server add Bob rx to the /home/Secr folder (see below).

3. Using Windows Explorer browse to //server/Secr. To the Prj and 32x folders, right-click, Properties, Security, Advanced, Edit, Add, add user Bob, check "Traverse" and "List folder". Apply permissions to "This Folder Only".

4. Repeat for the XLS folder, except add all permissions but "Full Control", "Change Permissions", "Take Ownership". (Even with these unchecked, Windows is still granting "Full Control" to XLS folder, must be a limitation of POSIX ACL) Apply permissions to "This Folder, Subfolders and Files".

Bob should then be able to browse to S:\Prj\32x\XLS and write the files under it*. New files under XLS should have Bob's rw permissions. Other relevant items from the smb.conf (some of these may be redundant or obsolete, things were added during troubleshooting that may not need to be there):

One issue you'll run into is if you need to add another group to the root share with rwx you can't use Windows to modify the ACL for this, ie the \\server\Secr folder. If you want to add the Ltr group to have full control of the Secr share then first add to the samba share as follows

Then use setfacl to add the Ltr group to the Secr folder. From the /home folder:

The first adds the group Ltr to the Secr folder. The second adds the Ltr group to the Default Group list which allows the permissions to propagate to new folders created under Secr. Use -R to add the permissions to existing files/folders. "Getfacl Secr" should look something like this:

*For some reason now using Windows to apply permissions isn't propagating to existing files/folders even when selecting to apply to "This Folder, Subfolders and Files". I was able to get that to work using setfacl:

I'll keep testing this. I'm likely missing something but at least unwanted permissions on new folders aren't propagating like they were before.

Okay to apply your new permissions to existing files using Windows right-click the folder, go to "Properties", "Security", "Advanced", "Edit", and there's a check box that says "Replace all existing inheritable permissions...". Change your permissions, check that box and click Apply.