December 2005 - Installer-dev

Re: Admin vs Root Authorization
by Andy O'Meara 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcX20NNiEb/oDGLEEdqqawAKlaBZUA== Thread-topic: Admin vs Root Authorization User-agent: Microsoft-Entourage/11.2.1.051004 On 12/1/05 5:07 PM, "Tobias Peciva" <peciva(a)pharos.co.nz> wrote: > On 2/12/2005, at 9:32 AM, Andy O'Meara wrote: > >> I realize that ideally, it's nice to have the user drag over an app >> from the img to wherever they like, but in situations where you >> have a suite of apps, this doesn't work as well. Our situation is >> that we need to copy a folder to the user's Application Support folder > > I think the official party line is that in cases like this, you > should place the support files inside your application's bundle and > copy them to the required location the first time the application is > run (if they are not already there). Thanks, but let me clarify a bit, since you're making some (false) presumptions. Our software is an engine/bundle that's used by our (proprietary) apps and iTunes plugins. This engine and its support files are installed to the user's App Support folder, allowing our iTunes plugin and apps to find and load it. The basis for sharing this engine (and not putting a separate copy in each app bundle) is that the engine bundle and support files are too numerous to embed, not to mention other significant reasons). > And if the user accidentally deletes the support > files, or drags the application to another machine on the network and > launches it there, it will still work, because your app will again > copy the support files to the appropriate location. N/a, based on the above; we can't dist the engine inside each app that uses it (a critical feature is that you can select from the different engines available--we have a couple and more are on the way) > Of course, Application Support is only writable by admins, so you do > need to take that into account. Not the user's--that's where our pkg currently installs to--you may want to review my previous post. You can drop by soundspectrum.com and download the software if you'd like to check it out--it may look familiar. Andy _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Admin vs Root Authorization
by Tobias Peciva 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 2/12/2005, at 9:32 AM, Andy O'Meara wrote: Cheers, Tobias _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I realize that ideally, it's nice to have the user drag over an app from the img to wherever they like, but in situations where you have a suite of apps, this doesn't work as well. Our situation is that we need to copy a folder to the user's Application Support folder I think the official party line is that in cases like this, you should place the support files inside your application's bundle and copy them to the required location the first time the application is run (if they are not already there). This way, you still have a single drag install. And if the user accidentally deletes the support files, or drags the application to another machine on the network and launches it there, it will still work, because your app will again copy the support files to the appropriate location. Of course, Application Support is only writable by admins, so you do need to take that into account. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Admin vs Root Authorization
by Andy O'Meara 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcX2tmptqMLHsmKpEdqqawAKlaBZUA== Thread-topic: Admin vs Root Authorization User-agent: Microsoft-Entourage/11.2.1.051004 > > It's tough, because if we lock down the system more, users are asked > for a password more often, which makes the system less secure in the > long run. Yeah, I don't envy Apple on this one--it's a tough, tough problem to address--the remedy is a lose/lose. Unfortunately, for windows, they're exhibit A of how bad things can get (many apps these days require admin to install *and* run). A very tough problem indeed, and an even tougher one to pull out of once you're in it as I'm sure Redmond is painfully aware. > We really depend on developers like yourself making the right > decisions here, using 'admin' or 'root' authentication in the > installer only when you really need it, and using the correct one of > 'admin' vs 'root' depending on whether it's something the user should > be strongly alerted to. Perhaps a direction to consider for big-picture mac os authentication changes is the fact that most pkgs only want admin access in order to copy over their app(s) to the common Applications folder. I realize that ideally, it's nice to have the user drag over an app from the img to wherever they like, but in situations where you have a suite of apps, this doesn't work as well. Our situation is that we need to copy a folder to the user's Application Support folder, so if we were to go with the user-drag approach, when they opened our img, they'd see three items: App 1.app App 2.app App Support.pkg Suddenly, to the novice user, there's a couple steps needed to install the software. And those steps are perhaps written in a readme, which makes a 4th item (and requires a user to read them). Finally, in our case, our pkg uses an "Installation Files" alongside our pkg (by popular request from power users that refuse to use installers that require admin access that shouldn't). Now we have: App 1.app App 2.app App Support.pkg Installation Files Readme So, our poor novice user may get a little overwhelmed (or annoyed) that the installation process has become something they actively need to engage in. So, back to my initial suggestion, a pkg getting write access to the common apps folder (and only that access) would seem to be a useful access level/flag to have (and the user auth prompt could reflect this lower access level). With this, our img would now only need to contain 2 items: Installer.pkg Installation Files (now also contains the .apps that are moved to the Applications folder). And, most importantly, the pkg would not require admin auth, just the special-access level auth that I described above. I just came up w/ the above idea off the cuff, so if it's got holes/problems, you need'd reply--just something to think about. Andy _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Admin vs Root Authorization
by Peter Bierman 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com 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_. -pmb _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… At 1:23 PM -0500 12/1/05, Andy O'Meara wrote: Heh, don't worry, we're very aware of the issues surrounding how often users are asked for an admin password, and how many users run as an admin by default. It's tough, because if we lock down the system more, users are asked for a password more often, which makes the system less secure in the long run. We really depend on developers like yourself making the right decisions here, using 'admin' or 'root' authentication in the installer only when you really need it, and using the correct one of 'admin' vs 'root' depending on whether it's something the user should be strongly alerted to. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Admin vs Root Authorization
by Andy O'Meara 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Setting IFPkgFlagIsRequired
by Karl Schramm 01 Dec '05

01 Dec '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks! Karl Schramm _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… Is there a way to set the IFPkgFlagIsRequired flag for a package with PackageMaker? Right now I'm doing it manually and that's a bit of a drag. This email sent to site_archiver(a)lists.apple.com

1 0