Privileged Operations on macOS

Every few years I look at SMJobBless() for TeX Live Utility, shake my head, and continue ignoring the deprecation warnings for AuthorizationExecuteWithPrivileges(). Honestly, I expected SMJobBless() to be replaced by some new, under-documented fad by this time.

I can't help but continue to read these blog posts, @mjtsai, and become gloomier and gloomier with respect to Apple. Having read Ms. Vashchenko's work, I am left to wonder what level of expertise even exists at Apple anymore. They clearly don't "engineer", everybody must have decided to be a "designer"… and there is obviously no over-arching "security architecture" at play. I fear that @Rosyna might pop in here and give me grief, but… it is all just so depressing. Apple had the greatest comeback with OS X, bringing the power of UNIX to our Mac community like it did, and then… has seemingly squandered it. Linux, meanwhile, has rocketed forward, with a much clearer security architecting, actual "engineering" visible for all to see! Even Microsoft has changed their stripes! Are we in the Upside Down??
Meanwhile, as I see this stuff, year after year, mistakes that the "great" developers that Apple claims to employ just should not be making, no how, no excuses… no documentation (Inside Macintosh, anyone?), poor examples, outright wrong and insecure code… what am I left to think? macOS Catalina is, IMHO, a pile of bailing twine and spit-gum it seems. And we -assume- iOS is secure; but why? How? We can't investigate it. Seems it—if it is dealing with the same garbage code as macOS, same poor level of developer competency—is likely more security through obscurity than otherwise. We're one or two big ones away from a full-blown Windows XP morass.

I remember arguing during the OS X beta/early days on the Apple email lists, where at least much of the initial architecting was being laid out publicly (thankfully), for Apple to adopt a better Installer.app, or at least better Installer.app policies, more inline with how Installer on Classic Mac OS worked. Back in Classic, you could roll your own installer, but most users KNEW that was gross; if you used Apple's installer tech, it was a pain in the butt, but it also constrained what could be done. It was "safe". But here we are, 20 years on, and we're allowing 3rd parties to roll their own root injectors, "safely" hidden behind our account admin password typed into a pretty generic dialog box that every Tom, Dick, and Jane will inevitably put their password into. This is disturbing… macOS isn't secure, it is a complete security mess that's frantically racing to stem the tide of the all the holes in the proverbial dike. I remember the Windows-hell days prior to Windows 7… I don't wish to return to them. I certainly don't wish to find myself there on my beloved Macintosh. But I fear, as with COVID, it is just a matter of time now. And Apple has shown no actual, serious interest in doing what is necessary—a full stop reset and re-evaluation—to fix it. And this idea that somehow there is macOS and then there is iOS and there is iPadOS… folly. Even Microsoft was never so dumb.

(OK, yeah, Microsoft has been that dumb. But not the example Apple should follow!)

>Are we in the Upside Down??

I don't know if you've noticed everything else that has happened in the past four or so years, but we're very clearly not in the Upside Down. We're just the poor bastards stuck in the bad timeline that will probably disappear any second now when the heros fix the single past mistake that triggered all of this mayhem. I guess it's at least a small bit of consolation to know that in the proper timeline, Mac OS X is still great and Microsoft is still evil :-)

I am left to wonder what level of expertise even exists at Apple anymore. They clearly don’t “engineer”, everybody must have decided to be a “designer”

I understand the frustration, but that’s clearly not true at all.

(It’s also insulting to imply that “designers” are somehow lesser. UI design and visual design are hard. Not to mention, so is chip design.)

A few years back, Apple shipped APFS, and the remarkable part was how they really didn’t need to talk about it at all. They just quietly migrated everyone on iOS 10.3 or macOS 10.13. I’m not aware of any dataloss. That’s quite an engineering feat. I do wish for more; in particular, I wish Time Machine would take better advantage of APFS snapshots at this point (I want my block-level diffs, dammit!).

They also have some of the best hardware engineering talent out there. The Apple Ax line of processors destroys any other ARM-based CPUs at single-core, and rivals Intel CPUs that run at ten times the wattage.

So I don’t think Apple lacks engineering. Maybe they don’t have the right priorities; clearly, they could use some help (from an outside perspective) on documentation and quality control. And maybe some of the more frivolous features (but can we really agree what those are?) should be postponed in favor of important ones (but which are those?).

But, yes, they still do engineer.

And we -assume- iOS is secure; but why? How? We can’t investigate it.

There’s quite a bit that can be done auditing security without getting access to the source code. Apple makes claims in their iOS security guide, and many of them can be verified.

Seems it—if it is dealing with the same garbage code as macOS, same poor level of developer competency—is likely more security through obscurity than otherwise. We’re one or two big ones away from a full-blown Windows XP morass.

I really don’t know what gives you that impression at all.

Back in Classic, you could roll your own installer, but most users KNEW that was gross; if you used Apple’s installer tech, it was a pain in the butt, but it also constrained what could be done. It was “safe”. But here we are, 20 years on, and we’re allowing 3rd parties to roll their own root injectors, “safely” hidden behind our account admin password typed into a pretty generic dialog box that every Tom, Dick, and Jane will inevitably put their password into.

Back in Classic, literally everything was root. Nothing about that was safe. You could write a System Extension which basically corresponds to today’s kernel extensions, which are increasingly getting deprecated, and have always been discouraged.

If anything, one could argue that portions of macOS are getting locked down too tight. (Want to run an unsupported Nvidia graphics driver? Tough.)

I remember the Windows-hell days prior to Windows 7… I don’t wish to return to them.

I actually think you’re painting Mac OS Classic with rose-colored glasses while at the same time painting Windows worse than it was. Windows XP and beyond were NT-based, which in many was was like the Mac OS X Unix foundation. The details of why XP was still quite a vector for malware are far more complex than that.

And this idea that somehow there is macOS and then there is iOS and there is iPadOS… folly.

Why?

(Keep in mind that, really, macOS, iOS, iPadOS, watchOS, tvOS, bridgeOS, audioOS, and I’m sure I’m forgetting one are largely the same OS. They all run on top of XNU, they all run many of the same low-level frameworks, they run several of the same applications albeit for different user interaction at the high end, and the one big difference is the UI frameworks. Of those, macOS is really the outlier, but they’re closing that gap bit by bit. They’re still all descendants of NeXTSTEP, really.)

I guess it’s at least a small bit of consolation to know that in the proper timeline, Mac OS X is still great and Microsoft is still evil :-)

As a kid, that was my headcanon, but now that I’ve grown and also done full-time Windows GUI work, I wonder if there ever truly was that much of a difference. Steve may have had a point with “the problem with Microsoft is they have absolutely no taste”; I still think the icon design of Windows 95, just in terms of color scheme and all, isn’t pleasant, whereas Platinum was. But also, there were plenty of things even at the time that Windows did better than Mac OS.

Such as, y’know, I can type \\someServer\some\path\to\a\file.pdf as a path somewhere and it opens that file, transparently, from the network, without me having to fiddle, Unix-style, with “mounting” a network share. It’s not perfect, but it sure feels more reliable and nicer than the status quo as of macOS 10.15.

@ Sören

A few years back, Apple shipped APFS, and the remarkable part was how they really didn’t need to talk about it at all.

Um, they didn’t talk about it, so people didn’t know enough details to give feedback, and they didn’t realize they had bungled the Unicode design until after they had shipped it. It took at least three different implementations, which differed between iOS and macOS, and multiple migrations, to eventually get it right. Remember the maintenance updates that took forever because they would silently convert your whole filesystem and then revert it? Remember the password-shown-as-hint and disk image data loss bugs?

Um, they didn’t talk about it, so people didn’t know enough details to give feedback

Oh, if we want to talk about things that Apple did poorly with APFS, I can think of a few.

Like the documentation shipping a year after macOS shipped with the file system.

Or that documentation still being limited to, well, scenarios that don’t actually reflect reality: “for read-only access to Apple File System on unencrypted, non-Fusion storage”.

Or the GUI Disk Utility in High Sierra being buggy as hell (the CLI diskutil luckily wasn’t).

they didn’t realize they had bungled the Unicode design until after they had shipped it.

Sure.

Remember the maintenance updates that took forever because they would silently convert your whole filesystem and then revert it?

I don’t know about “forever”. I think you’re referring to iOS 10.2 updates, which did conversion test runs. I don’t remember that being a problem, maybe because my 5S was at the time getting slow anyway.

Remember the password-shown-as-hint and disk image data loss bugs?

I do!

I feel like you’re taking my post out of context, though. I was responding to this:

I am left to wonder what level of expertise even exists at Apple anymore. They clearly don’t “engineer”, everybody must have decided to be a “designer”

You can argue that Apple should have gathered feedback before shipping APFS. And that those bugs shouldn’t have happened. I would also argue that they should’ve documented it the day it shipped (or before).

But I don’t think that the existence of severe bugs (that, let’s be honest, probably didn’t even affect 0.01%), or the arrogant/laissez-faire attitude towards third-party feedback and public documentation clashes with my contention that strong engineering still exists at Apple.

Perhaps there are too few engineers, and they do seem to be hampered by questionable priorities, but I’ll stick to my assertion that APFS shipping the way it did is proof that engineering culture is still around.

But, sure, I’m the Apple shill. Whatever.

Page 39 of the PDF suggests to add a version check like this:

info [CFBundleShortVersion] >= \"10.10.10\"

I question this is a good example, as this could be exploited just as well:

If one uses an older version with version "10.2", then if the above check is done as a string comparison (and that's what it looks like), it would think that the version 10.2 is greater even though it's not.

So, does someone know if the check is done smartly, i.e. are the numbers checked as separate numbers, separated by the ".", or is this a string comparison, and therefore vulnerable in cases like in this example?

@Sören Overall, I agree with you, but I take issue with the part I quoted (“they really didn’t need to talk about it at all”). Had Apple talked about it more, they might have avoided the initial design problems, and developers would have been better aware of changes that led to bugs in apps (looking up files by Unicode name, different sort ordering, different date precision). And from the user perspective, many people got hit with terrible performance on spinning disks, which could have been avoided if Apple had talked about the tradeoffs of formatting as APFS (or silently converted HFS+ to APFS when adding a password via Finder).

@Thomas Good question!

Overall, I agree with you, but I take issue with the part I quoted (“they really didn’t need to talk about it at all”). Had Apple talked about it more, they might have avoided the initial design problems,

That’s fair.

Sure. Thing is, my original comment wasn’t supposed to be a nuanced, thorough take on things Apple did well and poorly on APFS.

But you’re right: I think “they really didn’t need to talk about it at all” does apply to the general end user, but it doesn’t apply to those with more specific use cases, including me*, and it definitely doesn’t apply to vendors of disk utilities. I should have qualified, sorry.

*) I filed a radar years ago and never got an answer: macOS put me into a partition layout where I ended up with three adjacent single-volume APFS containers. Can you merge those? Can you move a volume from one container into another? I ultimately gave up and just recreated one unified container from scratch, which involved a lot of shoving data back and forth.

Between Disk Utility being buggy at the time and also poor diagnostics (a long-standing Apple problem), I still have no idea 1) what I / macOS did to make that happen, 2) if I could’ve done something differently without having to move data. And I think that situation hasn’t improved much.

And from the user perspective, many people got hit with terrible performance on spinning disks

Yes. Well, not only that: three years in, we don’t even really know what Apple’s plans are. What is their guidance for Time Machine, exactly? If HFS+ is inadequate today for reliability reasons, isn’t it then especially inadequate as a backup destination? But APFS clearly was designed primarily with flash storage in mind (and lacks some features TM currently relies on). Will they add more hard disk features to make it appropriate? Is their heart in this?