Re: Admin vs Root Authorization
Re: Admin vs Root Authorization
- Subject: Re: Admin vs Root Authorization
- From: "Andy O'Meara" <email@hidden>
- Date: Thu, 01 Dec 2005 13:23:35 -0500
- Thread-topic: Admin vs Root Authorization
> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden