Best Way to Override 'Everyone - Read Only' using ACLs

Question

Hi, let me first clarify that I'm not an 'official' network administrator, I'm just the only one in a small design office able to attempt to figure this stuff out.
We are needing to upgrade our security in a small office (5-7 users, 1 server running OSX Server 10.4.4).
We've been working great since OSX Server 10.3.x using standard POSIX privileges setup as follows:
Owner: Our_Server - R/W
Group: OurGroup - R/W
Everyone: None
We've been able to share files great as we're all in the same group (OurGroup). No problems.
Unfortunately, we now need to add a higher level of security for some incoming freelance workers. Essentially, we need to give them access to only certain folders UNDER our main Share Point directory. But we need to retain all of the freedom we've always had for the entire Shared directory.
From my understanding, the only way to do this is by using ACL's and a different group for the freelancers. I've setup a TEST directory to try this on. I've almost got it setup to work the way we want, but now am experiencing what I've discovered to be one of the drawbacks of using ACL's - the "Inherit Permissions from Parent" feature of AFP is no longer an option.
So using this method, new files added by default pick up the standard POSIX permissions, which allow Read access to Everyone. And I have to 'replicate' the behavior of 'Owner' and 'Group' that we had working before using POSIX or the group would end up Read Only.
- Any way to simulate the inherited permission of 'Everyone: None" using ACLs?
- Is there an easier/better way to allow access to only certain sub-folders of our main Share Point for a different group (FreelanceGroup)?
- Any way to do this while keeping our good working POSIX model?
- What should my POSIX access settings be set now when using ACLs?
- How dangerous is having 'Everyone: Read Access' really? We have guest access disabled, appropriate firewalls, etc.?
Thanks a lot. I hope I'm approaching this properly. I'm open to any tips. We just need to make sure nothing 'appears' to change too much in the workflow we have grown accustomed to (within reason).
G5 Dual 2Ghz   Mac OS X (10.4)   1.5GB RAM

Answer 1

If you haven't already, you may find my ACL Tips post helpful: http://discussions.apple.com/thread.jspa?messageID=1696702
My best advice would be to concentrate on defining ACLs for the groups of users for whom access should be granted (Allow rules). These can define inheritance for newly created files and folders, and you don't have the limit of having to think about just one group and everyone else. Remember that the POSIX "everyone" group is actually "everyone else" - that is, any valid user (guest if guest access is enabled) who does NOT match the owner or who is NOT a member of the POSIX group. The way that POSIX permissions are calculated, the connecting user is always granted ownership if possible, then group membership (primary group first, membership lookup by GID second) if that fails. Failing the two, the everyone else permissions are returned.
Here's an example that highlights the difference:
There is a group called "everyone" - that's actually all users, guests included, if guest access is enabled. This group is NOT the POSIX everyone else field. Rather, if you grant an ACL deny for everyone, then that covers all users, not just those for whom you don't have an ACL defined!
Further, there's an "authed users" group, which is the group of all authenticated users (and it never includes guests, even if guest access is enabled). Like the "everyone" group, membership is calculated by GUID by memberd. So you can thinnk of these two groups as "smart groups."
Since the "smart groups" have membership controlled by memberd and GUID values, it's wise to only use them when defining ACL entries. Neither should be used for the group value of the POSIX group field. Either membership calculation will fail, or the "everyone else" POSIX field may never need to be consulted.
As to the missing "inherit from parent" feature, the story is just the opposite: ACLs actually give you better inheritance than that feature ever did. For example, ACLs each support inheritance with the file_inherit, directory_inherit, only_inherit, and limit_inherit controls. For each entry, you can have a group or single user's ACL entry apply to new child files, new child folders, or both. Further, you can control inheritance on a per-folder level, and manage how deeply that inheritance goes (limit_inherit) or whether the permissions are only inheritable.
For example, your example POSIX group permissions would look like this using two ACLs:
ourgroup allow readattr,readextattr,readsecurity,list,search,read,execute, write,delete,append,deletechild,add_file,add_subdirectory,writeextattr,writeattr,file_inherit,directoryinherit
Again, my ACL Tips post explains more, and my answer to this post clarifies how new files, copied files, and moved files/folders get their POSIX and ACL permissions: http://discussions.apple.com/thread.jspa?messageID=3188259&#3188259
Hope this helps!
--Gerrit