+ Post New Thread
Results 1 to 4 of 4
Mac Thread, ACL, POSIX and Permissions? in Technical; I'm struggling to get my head round ACL, POSIX and Permissions on the Macs, in that I don't quite get ...
  1. #1
    theeldergeek
    Guest

    Question ACL, POSIX and Permissions?

    I'm struggling to get my head round ACL, POSIX and Permissions on the Macs, in that I don't quite get which one takes precedence over the other and so on.

    For example, if I set an ACL on a folder in 'Server Admin', does that have priority over a POSIX setting, and what if I change the permissions directly on a file within that folder using 'Get Info', does that overwrite the ACL?

    Is there a hierarchy of permissions?

    The long and short of it all is that I need to find out once and for all, so if someone can explain to me in the most basic of terms, or point me to an idiots guide, I'd find that very useful!

    FWIW, we have iMacs running OS 10.5.7 with an xserve for users home drives.

    Many thanks in advance

  2. #2
    AntonioRocco's Avatar
    Join Date
    Oct 2008
    Location
    South Yorkshire
    Posts
    270
    Thank Post
    11
    Thanked 114 Times in 95 Posts
    Rep Power
    41
    Hi

    Prior to 10.4 Server you only ever had Standard UNIX (or POSIX-style) Permissions. This was a permissions model that, although effective, was limited in its scope.

    Apple changed this with 10.4 Server. Access Control Lists were introduced and they worked in conjunction with the default standard POSIX model. To utilise ACLs you had to enable them on the volume first followed by a restart. ACLs take precedence oer standard POSIX. A deny in both models blocks access to the specified directory/file. A deny in POSIX but an allow in ACL means users can access the directory/file once the correct authentication details are entered.

    On the client side all directory/files carry with them standard POSIX permissions and these are honoured. In other words locally applied permissions 'follows' the file/folder.

    For example user Johnny creates a TextEdit Document on his 10.4 Client Mac. Locally on his Mac the OS will apply the standard POSIX Model. He automatically becomes the owner with full access. Anyone in the local admin group is assigned read only access as well as the local everyone group being assigned the same permission. Johnny copies the file over to a designated share on his 10.4 Server which has not had ACLs enabled. However this share has been configured to allow Everyone full access using the standard POSIX model. The file once copied 'acquires' the share's given permissions. Suzy comes along and accesses the share point and has full access to the file created by Johnny. Full access on the standard POSIX model means read, write, delete.

    Now apply ACLs to the volume on the 10.4 Server. This time you define an ACL to the same share denying the ability to delete any files/folders. When Suzy or Johnny access the share they can still read and write but can't now delete. As you can see both models are in effect but the ACL has superseded standard POSIX.

    Do you understand the distinction?

    In 10.5 (Server and Client) standard POSIX is deprecated in favour of ACLs. ACLs are the default Permissions Model. If you have a 10.4 Server not configured to use ACLs but your clients are 10.5 this can/will cause permissions problems sooner or later.

    Why?

    Imagine this time Johnny is sitting at a mac with 10.5 Client installed. The Server is still 10.4 and ACLs have not been enabled. When Johnny creates the file and copies it over Suzy will only have Read only permissions. Even though the share has been configured using the standard POSIX model to allow Everyone full access, she still won't be able to do anything other than Read only.

    Why?

    You have to look at what happened locally for Johnny on his 10.5 Mac. Johnny creates the file but unlike the 10.4 Client Mac the file also acquired an ACL in addition to the standard POSIX model. To everyone else, except Johnny working locally, this ACL is 'masked' and can't be viewed. The only indication you have that the file/folder has an ACL applied is to launch terminal and issue:

    ls -lae /pathtofile/folder

    You should see the @ symbol at the end of the entry. This signifies an applied ACL. It is this ACL that denies Suzy access when she tries to access the file. The way around this is to enable ACLs on the 10.4 Server and define permissions using that model instead.

    On 10.4 Server ACLs were not enabled by default. As already mentioned you had to enable them (either using the GUI or the command line) followed by a restart.

    Unlike 10.4 Apple have removed the ability to disable/enable ACLs on a given volume from the interface in 10.5. To disable ACLs on a volume launch terminal and issue:

    sudo fsaclctl -p path -d disable (where path is the volume)

    To re-enable ACLs:

    sudo fsaclctl -p path -d enable (again where path is the desired volume)

    Whenever disabling and enabling ACLs the Server must always be restarted. Strictly speaking this should only apply to the boot volume itself. However it is good practice to do this for other volumes - internal or external, RAID or otherwise - as ACLs tend to 'take' better.

    On 10.5 Server ACLs are enabled by default and since 10.5.4 I don't think it's wise to turn them off either. Leastways I've never tried it. Besides if all your clients are 10.5 what would be the point? Files/folders copied or amended on a 10.5 Server with ACLs disabled would be a recipe for disaster for the reasons already mentioned.

    My conclusion and advice is to always use ACLs (either 10.4 or 10.5) and don't bother with standard POSIX. The propagation tool in Server Admin GUI is actually not too bad. However some people have had problems making ACLs 'stick' using the interface. This is usually because the volume/directory has a problem or the Volume has been shared rather than a directory/folder or the share point itself is a legacy one copied over from previous versions of the server or from a 3rd-Party Server using a permissions model not easily transferable. For example a share originally created on a legacy Windows Server or PC. For legacy shares it's best to create a folder/directory using Server Admin itself and to copy over files/folders. You could use robocopy or similar (from the PC side) or scp, ditto, rsync or similar (from the Mac side). Once copied propagate accordingly. Never share a volume because permissions don't propagate as easily. Always leave the standard POSIX permissions at their defaults: root (or admin) as the Owner with R/W; admin as the Group with RO and Everyone as RO. Don't fiddle with these unless you want to set the Everyone permission to 'None'.

    This is actually a useful feature as it denies anyone who is not the POSIX owner or group the ability to see the share. Be careful when applying a deny in both models as this can have dire consequences.

    Never Ever use the Finder to define permissions. Poor practice if on a client OS and a definite 'No' on Server OS. Always use the interface (on the Server) or the command line (Server and Client). The command line utilities chmod, chown and chgrp are the ones I mainly use. You can view the manual pages for each utility by launching terminal and issuing:

    man chown

    and so on. The manual pages generally have usage examples. Failing that you can always Google for an example or download the command line utility admin manual from Apple's website itself. Be advised that not all command line utilities have manuals and not all manuals are either correct or even up-to-date. This is not necessarily because Apple are lazy it's just the way it seems to be in the POSIX world. A lot of these binaries and shells have been around since the very beginning. The guys who developed them have either not bothered to keep them up to date or have moved on to something else.

    Finally for a more rounded understanding of both models I can't think of anything better than reading Gerrit de Witt's series of articles:

    Apple - Support - Discussions - ACL Tips ...
    Apple - Support - Discussions - ACLs all screwy ...

    The first one is for 10.4 Server where the principles are outlined and gone into great details. The second is for 10.5 and has some useful examples and explanations.

    Does this help?

    Antonio Rocco (ACSA)

  3. 3 Thanks to AntonioRocco:

    Arthur (7th August 2014), Marci (26th June 2009)

  4. #3
    theeldergeek
    Guest
    Quote Originally Posted by AntonioRocco View Post

    Does this help?
    No, could you run that by me again....

    Seriously, that's brilliant. I haven't digested it all yet, but I'm sure it will be very informative and useful when I do.

  5. #4

    Join Date
    Aug 2014
    Location
    Switzerland
    Posts
    1
    Thank Post
    0
    Thanked 0 Times in 0 Posts
    Rep Power
    0
    Wow. That's the best answer to a question I think I've seen on any forum! I never did get the difference between ACL and POSIX but you laid it out so clearly. I wish we had someone like you doing our IT stuff... I'm strictly a self-taught amateur.



SHARE:
+ Post New Thread

Similar Threads

  1. Squid3 - ACL
    By Hightower in forum *nix
    Replies: 6
    Last Post: 23rd January 2009, 12:32 PM
  2. ACL
    By kevin_lane in forum Coding
    Replies: 1
    Last Post: 19th December 2008, 07:09 PM
  3. joomla acl
    By alonebfg in forum EduGeek Joomla 1.0 Package
    Replies: 1
    Last Post: 21st March 2008, 05:19 PM
  4. squid acl
    By browolf in forum *nix
    Replies: 20
    Last Post: 20th April 2007, 09:55 AM
  5. ADMT and or Scripting ACL changes.
    By pete in forum Windows
    Replies: 4
    Last Post: 25th October 2006, 09:38 PM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •