ACL POSIX - Rules of Precedence

Question

Level 1

120 points

ACL POSIX - Rules of Precedence

Hello,

Having some problems with this.Workgroup manager states "Access Control List entries take precendence over the standard permissions listed above" yet, when I read Apples own File Services Administor PDF it says :

"When you add ACEs to an ACL, order is important. Mac OS X Server uses the following
rules to control access to files and folders:
• If a file or folder has no ACEs defined for it, Mac OS X Server applies the standard
POSIX permissions.
• If a file or folder has one or more ACEs defined for it, Mac OS X Server starts with the
first ACE in the ACL and works its way down the list until the requested permission is
satisfied or denied. After evaluating the ACEs, Mac OS X Server evaluates the
standard POSIX permissions defined on the file or folder. Then, based on the
evaluation of ACL and standard POSIX permissions, Mac OS X Server determines
what type of access a user has to a shared file or folder.ation for OSX Server 10.4 it states "

So it seems its a combination of both POSIX and ACLs which determines a users access.Sadly on my system it doesn't seem to work this way.

I'm trying to set up folder for our production dept.I only want the production group to have access.

So I set the Posix entries as :

owner - localadmin - read and write
group - admin - read and write
everyone - none

Then I add an ace for the production group, giving them full access.

I fire up the Effective Permissions Inspector, drag over a production member and find all the write attributes are off except for delete.So the everyone posix field definitley overrides my ACL settings. Now I can set the Posix everyone field to read and write but I don't want everyone to have access.

I thought about adding an ACL entry to the effect of denying access to all maybe by using the staff group.However deny permissions override other permissions, as stated in Apples File Services PDF.

All this coupled with the fact that once ACLs are enabled all files copied under AFP receive standard Posix permissions makes OSX a very poor fileserver.

Anyone got any ideas about how to setup this very basic share?

Thanks Guys.

imac G5, Mac OS X (10.3.9)

Posted on Feb 6, 2007 8:39 AM

Reply

Answer 1

Feb 6, 2007 8:56 AM in response to babatone

a) ACLs are directly attached to files/folders
b) ACLs propagate at file/dir creation time of new files

a+b) Existing files ACLs must be propagated manually in WGM

-Ralph

Reply

Answer 2

babatone Author

Level 1

120 points

Feb 6, 2007 9:52 AM in response to slowfranklin

Hi, Thanks for the reply.

I have been propagating permissions, I think thats the only thing I didn't mention.

I looked again at my setup, I missed something.When I check the effective permissions the write attributes are all ticked on not off as I previously said.

Nevertheless, when I try to login using that user they cannot even see the share listed.If I set the everyone field to read or read and write they can see the share and get in.

It seems like my system is totally ignoring the ACLs.

I'm going to set up a 2nd server on a separate network and check it out there.

Reply

Answer 3

Feb 6, 2007 10:05 AM in response to babatone

Did you kick memberd in the ***? If not, do so: memberd -f (afair, s. man memberd). Sometimes its all that sticky that a server restart is the only way.

-Ralph

Reply

Answer 4

Feb 6, 2007 11:32 PM in response to babatone

The Apple manual is correct regarding how ACLs interact with POSIX permissions. If you haven't already, please see my ACL Tips post, which gives you some more detail: http://discussions.apple.com/thread.jspa?messageID=1696702.

And, here's my answer to a question regarding how permissions for new/copied/moved files are assigned: http://discussions.apple.com/thread.jspa?messageID=3188259&#3188259.

According to your post, I see two possibilites: One, you've recently enabled ACLs without restarting your server. If that's the case, a restart will work.

Or:

I fire up the Effective Permissions Inspector, drag over a production member and find all the write attributes are off except for delete.So the everyone posix field definitley overrides my ACL settings. Now I can set the Posix everyone field to read and write but I don't want everyone to have access.

Do you mean that all write attributes are ON except for delete? If so, then there's the second possibility:

The Finder and some other applications are not yet fully ACL-aware. For example, if all write permissions are granted except for delete_child and delete, then the Finder will treat the folder/file as read-only. This is also a problem for applications that employ saving routines like TextEdit. Basically, this situation cannot presently be resolved without further application improvements. Yes, the filesystem and core OS are ACL-aware, and effective permissions are being calculated correctly, but Finder/TextEdit represent a set of applications that depend on POSIX-like ACL mixdowns. This means that, even though ACLs offer fine-grained read and write permissions, some applications don't respect them when they're told.

So why even have ACLs? Well, right now they fix several problems with POSIX-only: (1) nesting groups, (2) defining new/copied file/folder inheritance, and (3) the ability to define permissions for more than just one group (POSIX group) or user (POSIX owner) at a time.

Hope this helps.

--Gerrit

Reply

Answer 5

babatone Author

Level 1

120 points

Feb 7, 2007 4:38 AM in response to babatone

A restart sorted it out, as simple as that.

The ACLs now override the everyone Posix field.

Thanks very much to both of you.

I also checked out the memberd process, memberd -r resets the cache.Is that the switch you meant ralph?

Or can I restart it another way. If I choose to quit the process in activity monitor it disappears and comes straight back with a different process ID. Is that the correct way to restart it?

Reply