Linux inherit file/folder permissions

it4soho:
The ACL's I meant are Linux ACL's not NT's ones. They work irrespectively from the SAMBA option.
I have a comparable problem with courier IMAP with shared folders. The courier imap daemon has no knwoledge of ACL's

You do need the packages installed as well as the options enables as it2soho states (fstab options)
Samba only adds a way translate between NT's ACL's & Unix's ACL's.

The tools are getfacl, setfacl, ACL's are a special case of the POSIX attributes managed with getfattr, setfattr. Support for ACL's exists in ext[234], xfs and reiserfs by addings the attributes to the filesystem data structures.
The attr & acl packages (on on most systems) supply the tooling & libraries required.

the line in fstab should contain the acl options in the options field

When you run getfacl, you need to think like a linux system -- which is to say, look for "a set of permissions" that you can apply to this user for this file. Once you find one (ANY one), stop looking and apply the ONE that you found.

This is why, for example - using traditional POSIX permissions - if a user "usera" belongs to the group "groupa" and a file "filea" has user ownership by "userb" and group ownership by "groupa" and permissions rw-r--rw-, then usera will NOT have any write permission to filea -- even though the "everybody" write permission is allowed!

Here's the "thought process" involved. "Looking for the FIRST permission that applies"
 - Is the user the owner of the file? <NO> If yes, STOP and use the user permissions
 - Is the user a member of the group-owner if the file? <YES> If yes, STOP and use the group permissions
 - Otherwise, use the "other" (aka: everyone or all) permissions

As you can see, we STOP at the group permissions because of the membership in the group "groupa", which is the group-owner of the file.

Now, in the case of ACL's you need to remember the rule, albeit now expanded for the ACLs. Since you've left out some very important details in what you've posted, I'm going to provide my own example.

Let's say I create a file at /home/public, owned by usera, group groupa and with permissions 666 (standard read/write for all -- it is named PUBLIC!)
OK -- just for grins, let's look at the output of getfacl:
  getfacl /home/public
  getfacl: Removing leading '/' from absolute path names
  # file: home/public
  # owner: usera
  # group: groupa
  user::rw-
  group::rw-
  other::rw-

NOTE how the output of getfacl lists user, group, and other -- so if you just progress down (although you do have to look above to see which user is THE user, and which group is THE group).

OK, so let's say we have a group called media who is NOT supposed to have write access... we'd do this
  setfacl -m g:media:r-- /home/public
And when we check our work, we see this:
  getfacl /home/public
  getfacl: Removing leading '/' from absolute path names
  # file: home/public
  # owner: usera
  # group: groupa
  user::rw-
  group::rw-
  group:media:r--
  other::rw-

Now let's be clear -- if usera belongs to the group media, they STILL have rw- permissions (user permissions come before group permissions so we actually never even checked for the group permissions at all!)

So, next, let's say that we have a special media person, user-id of director, that - despite being in the group media - needs write access... we'd do this
  setfacl -m u:director:rw- /home/public
And when we check our work, we see this:
  getfacl /home/public
  getfacl: Removing leading '/' from absolute path names
  # file: home/public
  # owner: usera
  # group: groupa
  user::rw-
  user:director:rw-
  group::rw-
  group:media:r--
  other::rw-

Now, when the user director accesses the file (step through this), the thought proccess in *nix is:
 - Is the user the owner of the file? <NO> If yes, STOP and use the user permissions
 - Is the user "director"? <YES> If yes, STOP and use the permissions for director
 - need I go on? So, you see I never even look at the permissions for the groups (much less other).

OK, so the confusing part comes in when we have "conflicts" -- and it will always be a group conflict (a user can have only 1 user-id, but can belong to multiple groups...

So, let's say we have another group, kids, that we want to remove ALL access for... so we'd do this
  setfacl -m g:kids:--- /home/public
And when we check our work, we see this:
  getfacl /home/public
  getfacl: Removing leading '/' from absolute path names
  # file: home/public
  # owner: usera
  # group: groupa
  user::rw-
  user:director:rw-
  group::rw-
  group:media:r--
  group:kids:---
  other::rw-

So, along comes user culkin (as in Macaulay Culkin -- Holywood actor and member of the media group, who for the purposes of this exercise, is still a KID) who therefore happens to belong to BOTH the group kids AND the group media... now follow along (step through this), the thought proccess in *nix is:
 - Is the user the owner of the file? <NO> If yes, STOP and use the user permissions
 - Is the user "director"? <NO> If yes, STOP and use the permissions for director
 - Is the user in the group of the file (groupa)? <NO> If yes, STOP and use the group permissions
 - Is the user in the group media? <YES> If yes, STOP and use the group permissions for media
 - I do NOT go on to see that he is also a member of the group KID... so those permissions will not apply

So, the operative question is "How do I make the REMOVE permissions of KID supercede the READ/WRITE permissions of media?" And the answer isn't a good one -- you make note that NEW permissions are added to the "bottom" of the list (new users to the bottom of the users list, new groups to the bottom of the groups list)... so you have to create a "heirarchy" (which ones come first). Then, you need to remove ALL of the group permissions and re-add them in the heirarchical order you decided upon. (not easy, and kind of brute-force, but the only way *I* know of).

Now, on to the issue of inherited ACLs -- Just as in getting ACLs to work at all in Samba (you had to enable ACLs in your filesystem (explicitly in ext3, it's already on with XFS) AND in your samba config file, you similarly need to separately enable ACL inheritance in Samba... in your GLOBAL section, add these lines:
      inherit permissions = Yes
      inherit acls = Yes

I hope that this helps explain the behaviors you're seeing as well as how to get MS Inheritance working.

Dan
IT4SOHO

First, you need to coordinate the mask & mode entries better, and drop the security mask entries ...

e.g.:

[RAID]
        path = /RAID
        writeable = yes
        browseable = yes
        valid users = media, usera
        create mask = 0760
        directory mask = 0770
        force create mode = 0760
        force directory mode = 0770


NOTE: The file create & force create modes are 760, not 770 because the execute bits are actually mapped to the DOS file permissions as follows:
  user execute permission on UNIX = Archive attribute on DOS
  group execute permission on UNIX = System attribute on DOS
  other execute permission on UNIX = Hidden attribute on DOS

Thus, if you created the file a.dat and gave it permissions 770, your windows clients would think it was a system file -- not likely what you wanted.

ALSO NOTE: These settings apply only to files that are CREATED in the share by WINDOWS clients. Linux users are governed by the internal Linux UMASK values.

I hope this helps!

Dan
IT4SOHO
 

BTW: Looking at the ORIGINAL question, I would posit that you don't even need ACLs:

user1 belongs to the groups user1 (from /etc/passwd) and users (from /etc/groups)
user2 belongs to the groups user2 (from /etc/passwd) and users (from /etc/groups)
media belongs to the group media

/share/user1 is owned by user1 & belongs to group user1 with permissions set to "drwxrwx---"
/share/user2 is owned by user2 & belongs to group user2 with permissions set to "drwxrwx---"
/share/folder1 is owned by anyone OTHER than media & belongs to the group users. Permissions are "drwxrwxr-x"

Then, from your question:
user1 would see:
/share/user1 rwx     by way of user rights on the folder (user1 is the owner)
/share/user2 ---       by way of other rights on the folder (user1 is neither owner, nor a member of group user2)
/share/folder1 rwx   by way of group rights on the folder (user1 belongs to users)
 
user2 would see:
/share/user1 ---       by way of other rights on the folder (user2 is neither owner, nor a member of group user1)
/share/user2 rwx     by way of user rights on the folder (user2 is the owner)
/share/folder1 rwe   by way of group rights on the folder (user2 belongs to users)
 
media would see:
/share/user1 ---       by way of other rights on the folder (media is neither owner, nor a member of group user1)
/share/user2 ---       by way of other rights on the folder (media is neither owner, nor a member of group user2)
/share/folder1 r-x    by way of other rights on the folder (media is neither owner, nor a member of group users)

In my personal experience, Windows users use ACLs far more often than they need to because they don't think out the logic. While the result sometimes makes things easier to see and understand, the result is also that there are often unintended consequences because they don't bother to think the logic out!

Now -- for inheritance sake, let's look at the 3 folders (I removed folder2 & folder 3, because they're just duplicates of folder1).
 - /share/user1 is accessible by user1 only - because the ONLY member of the group user1 is user1, and other permissions are ---. As a result, nothing really needs to be done. Any file created within will be owned by user1 by default, and no other user will be able to get to any of those files because they won't be able to get through the directory.
 - /share/user2 is in the same boat, but for user2
 - /share/folder1 however, will need a very slight bit of tweaking -- we want any new files created to belong to the users group, so we should turn on the UNIX SGID attribute (chmod g+s /share/folder1). The result is that an ls -l on the folder will now yield results that look like: "drwxrwsr-x" -- note the s where the group x would have been. This means that all files created in this folder will belong to the group users (because that's the default user for the folder). It ALSO means that any new FOLDERS created in this folder will have the SGID attribute turned on by default.

NOTE however, that if you're doing this after the fact, you'll want to run the following 2 commands:
 chgrp -R users /share/folder1
 find /share/folder1 -type d -exec chmod 2775 '{}' \;

These two lines will a) change the group membership of every file under folder1 to users, and b) turn on the sgid bit (after group membership has been changed) for any and all DIRECTORIES under folder1. (This chmod example shows the turning on of the SGID bit with the 2 in front of the 775 (rwxrwxr-x) setting).

Good Luck!

Dan
IT4SOHO