One example: given a file, you can create several different access levels. One group can be read-only, one group can have read and write but NOT delete, one group might only be able to modify permissions, and one group might have full access to the file, while "EVERYONE" has no access at all. Administrators, incidentally, need not have access beyond "take ownership" which is an obvious and easily-audited action.
These are all standard features in most ACL-based multi-user environments.
Unix file permissions don't use ACLs, so off the top of my head I'm not sure how you would set this up on Unix. For one thing, I am pretty sure w implies delete permissions. So that group can't even exist, and if it could, there's no easy way to have that group be different from the read-only group, and still have a no-access-at-all group.
I suspect most complicated requirements can be resolved with some combination of sudo and traditional permissions but it's not always straightforward and probably won't be exactly equivalent to the way you would do it in Windows.
And those ACL's are available within OS X as well, as well as within Linux, Solaris, FreeBSD (UFS2 and ZFS).
This complaint doesn't hold water. Those features are available within standard Unix environments (Solaris probably counts the most as a real Unix, OS X is technically certified Unix as well!).
So Unix file permissions can use ACL's. The default is POSIX file permissions but they aren't the only ones available.
It's not a complaint, it's just the way it is. The windows (NTFS and later) default security model uses ACLs. Unix doesn't. This gives windows a few minor advantages. Yes, of course you can do ACLs on Unix. If you really need them there are plenty of ways to do it. But the limitation I described is, nevertheless, a limitation of the default unix permissions model.
It's mostly pointless to debate whether one is "better" than the other. There are advantages and disadvantages to both approaches, and it's trivial to screw up permissions either way.
The biggest advantage of unix permissions is the culture and history surrounding them, as well as the design and conventional use of the system itself. On unix, application developers, maintainers and administrators have a pretty good idea about how permissions should be set. Generally, the need to run as root is fairly well quarantined to system administration tasks. It's not perfect, but it's much better than what I remember of windows, and a quick search suggests the situation hasn't much improved. Here's a user who discovered a problem using visual studio, he was able to solve it by running as Administrator:
If a unix OS were to abandon too much of the conventional unix way of setting permissions (regardless of whether ACLs are used or not), you could begin introducing similar problems.
The old standard file permission system is the default on most unixy systems because it's easy to use and understand (more or less). That doesn't mean these systems don't have ACLs.
I would say it's because that's conventional, it's what users expect, it's what many applications expect perhaps most importantly having ACLs is just not that important. It's not necessarily that it's "easy to use an understand."
In Windows, it's there by default. I'm not claiming that windows is better or more secure, I am simply answering the question that was posed.
These are all standard features in most ACL-based multi-user environments.
Unix file permissions don't use ACLs, so off the top of my head I'm not sure how you would set this up on Unix. For one thing, I am pretty sure w implies delete permissions. So that group can't even exist, and if it could, there's no easy way to have that group be different from the read-only group, and still have a no-access-at-all group.
I suspect most complicated requirements can be resolved with some combination of sudo and traditional permissions but it's not always straightforward and probably won't be exactly equivalent to the way you would do it in Windows.