How Mac OS X, 10 Today, Changed Apple's World 342
CWmike writes "Ten years ago today, Apple's first full public version of Mac OS X went on sale worldwide to a gleeful reception as thousands of Mac users attended special events at their local computer shops all across the planet. What we didn't know then was that Apple was preparing to open up its own chain of retail outlets, nor had we heard Steve Jobs use the phrase, 'iPod.' Windows was still a competitor, and Google was still a search engine. These were halcyon days, when being a Mac user meant belonging to the second team, writes Jonny Evans. We're looking at the eighth significant OS X release in the next few months, Lion, which should offer some elements of unification between the iOS and OS X. There's still some bugs to iron out though, particularly the problem with ACL's (Access Control Lists) inside the Finder. Hopefully departing ex-NeXT Mac OS chief, Bertrand Serlet, will be able to fix this before he leaves."
Re:played with the beta (Score:4, Informative)
At the time people were saying they'd just stick with yellow dog linux. Funny how times change
Yeah, hilarious. Xserves are dead now, and Mac OS X Server won't be far behind. Thankfully you can run CentOS on a 1U budget server and still use the yellow dog update manager. :)
Re:Windows "was" a competitor? (Score:4, Informative)
Re:Was a wise move by Apple (Score:3, Informative)
Not only that (Score:5, Informative)
But a lot of Mac's growth has been due to Windows running on it. We see that on campus all the time. People want a Mac for whatever reason. However they need software that is Windows only (this is particularly common in Engineering, where I work) or they are a gamer and want to play games that aren't on the Mac (see that with students a lot). Previously that might have turned them off from a Mac. However now they get one and then get Windows for it and maybe Fusion or Parallels. Our bookstore does a ton of business in Windows licenses and VMs.
So sure, more people are using Macs and OS-X but often it is in addition to, not at the expense of, Windows. Fine for Apple, they make money on hardware, but also fine for MS, they make money on software. MS doesn't care what you run Windows on, just that you run Windows.
Re:halcyon days? (Score:5, Informative)
Seriously, you think the use of some BSD code is what made the difference?
You do understand that their kernel, Darwin [wikipedia.org], uses XNU at its core, which is largely composed of the Mach Microkernel [wikipedia.org] and BSD [wikipedia.org]. Leveraging these mature projects spared Apple (NeXT, at the time) from having to design, develop, and debug a kernel from scratch.
Yes, this is a hell of a leg-up.
Re:Flamewars (Score:5, Informative)
The relevant visible parts of MacOS are pretty anti-unix actually.
Erm, no, Mac OS X is quite definitely 100% certified Unix [arstechnica.com]. This has nothing to do with the "visible parts" (you mean the GUI I assume), this is all about the underlying kernel and other subsystems of the OS, as well as some of the userland tools.
ACL bug, root cause (Score:5, Informative)
I don't know whether to laugh or cry... I used to maintain the ACL code in the Mac OS X kernel. This is a user-space bug in the DesktopServices framework.
Although this is not usually a problem, since only foolish/untrained administrators use Finder copies on systems being used as servers, I tried several times to get the Desktop Services folks to fix this. Mac OS X has multiple "copy engines", and the one in libc gets this right, while the one in the DesktopServices framework gets this wrong.
The problem is that the finder "copy engine" code sets an ACL in the openx_np() system call, rather than using the chmodx_np() system call after the fact to set an explicit ACL. The ACL it passes to openx_np() is obtained from the source file system object via getattrlist() (but could as easily have come from statx_np()). So the ACL being set is the combination of the ACL set explicitly by the openx_np(), and the ACL being set as a result of the inheritance bit on the container directory in which the new file or directory is being created.
This is in fact necessary, since the only way to make image backups of a subtree such that the copied subtree has exactly the same permissions in the target subtree as it had in the source subtree is to set *all* of the ACLs that were on the source object onto the target. Anything else loses permissions grants or denials on the copy of the object which were present on the original. This is either inconvenient, in the case of grants, or a critical security bug, in the case of denials.
You can also see where this would be a necessary step for a backup/restore operation, where the date is serialized into an archive format on the backup, and deserialized back into the file system on a restore, which could be a partial archive restore.
Things can get even more complicated when Time Machine and Spotlight are thrown into the mix, since Spotlight adds inherited ACEs to permit it to index directory contents that would otherwise be denied it by ACL, as does Time Machine (for some reason, they do not share a common group ID and utilize a single shared system functionality ACE, but I digress...). Likewise Time Machine sets an inherited ACE on its backup volume, for similar reasons.
The correct fix is to do ACE deduplication in the case that the target directory container has inherited ACE entries which match the ACE entries on the source object, and remove duplicates from those explicitly listed in the openx_np() call. The alternative approach is to explicitly set exactly the desired ACL on the target after the target is created -- this has the drawback that you would need to explicitly know the container ACLs inherited ACE list in order to aggregate it yourself, but has the advantage that you won't be denied access to the object during creation if your openx_np() ACL contains explicit rights grants for the group or user that the creating entity runs under (this should be coupled with a subsequent "deny everyone" ACE to avoid a security race, which makes this the less desirable workable solution).
Note that the above should make it obvious why a depth-first post-application of ACLs on copied objects wouldn't work; apart from the security problems in the order of operation window, network protocols such as AFP and NFSv$ and SMB all use connection credentials rather than request credentials (NFSv3 uses request credentials), and even privileged users do not have access to other users keychains or session passwords in effect for a given copy operation.
-- Terry