site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Thread-index: AcX2pFdSlgI3KGKXEdqqawAKlaBZUA== Thread-topic: Admin vs Root Authorization User-agent: Microsoft-Entourage/11.2.1.051004
Unfortunately, the installer itself can not determine if your package "should" ask for a password. 99% of the time, such packages probably should ask for a password and use "Root" authentication.
There's been plenty of confusion about this, even inside Apple, so the behavior of these flags is currently being reviewed and may change if we decide that "admin" authorization is an unnecessary risk.
The issue isn't capability, but notification. Asking users for their password in order to "alert" them to an unusual situation can lead to password fatigue, so in the case of the broadband tuner, someone decided that an extra "heads up" wasn't necessary.
Very interesting that you brought this up... Myself and a couple other devs on these lists have pointed out some big-picture kinds of issues with Mac OS X installers and authentication. Namely, it's starting to become the habit of any developer who authors a .pkg to require admin (or root) authorization even when it's not always needed... Allow me to paste from some correspondence with a colleague on the subject of whether or not to require admin (or no) authorization for our pkg. We were discussing about making our pkg also copy our .app to the common/global Applications folder (in addition to putting various support items in the user's Application Support folder) (note: we generally have a whitebelt level userbase)... // Snip //
I tend to lean towards installing in the common applications folder, because *most* users are in fact admin authorized. Since Macs ship with a default configuration of a single admin-authorized user, I imagine lots of naive users being admin authorized.
Well, the reality is there's lots of kids and lab users that don't have admin access. I consider this significant enough % not to require admin access. Also, more than once I've seen power users remark that the hallmark of crappy software is that it requires admin access when it doesn't need to (which, in general, I agree with).
On a related note, I predict, along w/ a number other devs, that the first major mac os x malicious attack vector will be some kind of service that takes root from latching on, putting up a fake/mimic auth dialog box, getting the admin credentials, and going to town. So any exploit that lets you inject code (even in the user security space), can easily get to admin space b/c the typical mac os x user shows no question/concern when any app requests authentication (because, imho, Apple needs to do a major rev in this area of mac os x). So, in short, I prefer not to be part of this (rising) deficiency if I can help it (another angle you can take is to look how bad that legacy has turned out for MS Windows).
Look at this Sony XCP stuff. Apparently, it targets Mac OS X as well, but it of course needs to auth prompt the user before it can write its nasty files in the right places. All well and good, you might say, until you realize that just about every single non-expert mac os x user out there won't stop to think why they're entering their password, who asking for it, and what that entity intends to do with it. Imho, it is very clear a better model is needed on mac os x to address this rising scenario. In other words, mac os x is a lot closer to the integrity wasteland of Windows than we sometimes care to think, and I think the XCP stuff for mac os x is cold, hard proof.
// Snip // Peter (and whomever), I encourage you to forward this to any potentially interested parties for consideration. I would be more than happy to file this in radar as an enhancement, but don't be upset if I think it'd get filed away like we say the Ark gets filed away in the end of the movie _Raiders of the Lost Ark_. Take care, Andy _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com