If you’ve ever used Adobe Air, you’ll notice that on Linux, Mac OS X and Windows Vista/7 you will be prompted for a password (or UAC “continue/cancel” prompt) in order to install an application. If you’ve ever wondered why, here’s both the technical answer and the “Adobe Answer” to this question.
The Technical Reason: Permissions
/opt, and the program files directory both require superuser/root/administrator permissions to write to in Mac OS X, Linux, and Windows Vista/7. Windows <= XP do not, however.
(another reason in Vista is because of the usage of NTFS junctions, but that's another rant)
Now, if I were Adobe, in addition to making PDFs not slow everything down, making Flash secure, and not bogging down users' computers with stupid startup "preloaders", I would install the app to a user-writable location such as ~/air on Mac OS X/Unix/Linux or %USERPROFILE%\air in Windows.
Those directories are writable via the current user, and thus wouldn't require a password in order to be written to. I would then feel much more at ease with installing Air applications, since my password would not have to be supplied to an Adobe maybe-secure application (where it can then be used to do other malicious things in addition to Adobe's intended function).
But there's another reason Air requires your password for installing apps...
Adobe’s Reason:
Implied-security. By making the user enter a password, if any, the user is authenticating themselves to Air (telling the Air installer that this user didn’t just wander up to the computer and install a malicious Air app) in addition to the permissions issue.
In addition to this, however, non-malicious users feel more at ease with using Air, hence the “oh, it needs my non-blank password, so I can trust this app” implied user reaction.
However, given Adobe’s security history, I wouldn’t trust my entire system’s integrity to the installation of an Air app. Sure, the password isn’t required every time a (possibly-malicious) Air application is launched, but it still makes me uncomfortable.
Those familiar with hot-patching via buffer-overflows know exactly what I’m worried about.
But, as long as normal Air users don’t read this, I think Adobe has us all fooled into a completely -false sense of security.










I just registered my business with an auction website firm that provides a program that eases the process of moving auction listing data over from other auction sites. They use Adobe Air as some type of facilitator for downloading their custom app. I just discovered that, despite running an IMac made in early 2009 with a Power PC Processor and running Mac OSX 10.5.8, Adobe doesn’t support PPC Processors, and I can’t install the app I need to run my business! Their customer service offered no work-around, there is absolutely no intention to help. I am now looking into remedies unde rthe theory of restraint of trade and have hailed class action attorneys…suggest if you are one of the other hundreds of thousands impacted, you stay tuned.
To Oliver, the AIR representative
Ad 1) You’re plain wrong, or purposely spreading misunderstanding. The default installation directories are for system-wide applications. User application may reside in home directories.
Ad 2) Your choice of user feedback was your choice, and to be honest this is the only feedback you get from me – no insults expressed.
Ad 3) Talking about linux, you are referring to Windows. Sure, pick whatever you like from Windows and use on Mac, and opposite. Logic for engineers is overrated.
Ad 4) Administrative support on Linux can disable any executable in the user directory without any effort whatsoever; what follows, you could make an installer with an opt-in to disallow air applications in user directories (since the user executables are not permitted anyway, user will have no such possibility, if the admins during installation would have such a choice). Doable easily, the matter for Your company must be of a different nature.
In general, I think AIR wants to have root privileges. “Either our way or the highway”.
regards,
Anonymous System Architect
Oliver,
Personally, I find this issue frustrating. I have been trying to push this environment, Adobe Air, as a suitable rapid development environment within the Department of Defense. Because the developer cannot overcome this issue, the prospect of using Adobe Air is fading. These kind of quirks are the reason why Microsoft dominates the technology sector in the U.S. government.
@Olivia
He’s referring to the way (for example) Python.exe’s installation requires elevated permissions, but .py files do not (unless modifying the system).
Same with Java, both of which do fine in enterprise configurations despite not requiring credentials or a specific installation location for .jar, .class or .py files.
So, back to the point: why does Air need it’s runtime programs to access user credentials in order to install, when they could just as well be put in the user’s home directory?
It just doesn’t make sense considering the alternatives, as Mark outlined.
Hi Olivia,
First let me welcome you to The Coffee Desk. Secondly, let me raise a few more issues regarding your reasons:
1) On Linux/Unix, the default install location is /usr/bin, /usr/local/bin, etc. On Mac OS X, this is /Applications, and on Windows this is the program files directory. Why do you use /opt again?
And on non-Windows platforms, it is perfectly valid to install a program (more specifically, a binary) to a user-writable folder (~). I’ve done the same on Windows, where the Registry can be used to locate shared libraries.
Even at that, you could allow “advanced users” to select a custom install location, a la Windows Installer.
2) And yet you have shortcuts pointing to the applications (post-installation) that go on the desktop. For most Windows users, a Start Menu shortcut to the installation directory would suffice in case a user “couldn’t find their applications”.
3) I’ve installed numerous security-intensive (read: Group Policy-heavy) Windows domains for businesses. If I don’t want them writing to a user directory, I probably don’t want them running an Air application, especially since most deal with Twitter anyway.
If I DO want them to use a company-specific Air application, I’ll install it for all to use either locally or on a shared drive, as I do with MSO or any other distributed application.
I am speaking for the Adobe Air binary itself, as this is required for the execution of the actual applications.
4) Again, I don’t mind giving permission to setup the Air runtime. It’s the installation of other applications requiring credentials I have a problem with.
If the Air runtime installed without trampling over a group policy or permission restriction, then I don’t care about running the Air applications EXCEPT for the fact that there is a possibility of having my network compromised due to some Air app stealing credentials.
Runtime installation: require credentials for installation, install in the usual OS-specific executable location.
Air Applications: install to the user home directory, don’t require any permissions, since the runtime is required anyways.
Seeing how Adobe has a history of illogical decisions, especially regarding enterprise deployments, this does not come as a surprise.
But, carry on. You just won’t see any Air deployments from me, on either home OR enterprise configurations, and I’d advise others to do the same.
regard,
Mark
Hi Mark,
Thanks for raising this issue. There are several reasons we chose the install locations we use, but it turns out that implied security is not one of them. Our reasons were:
1) OS Guidelines. The locations we are are, on all platforms, recommend install locations. (Mac OS does also have a recommended per-user install location, but Windows does not.)
2) User Feedback. In one of our early beta releases we used per-user install locations, as you suggest. The feedback we got was uniformly negative; people just didn’t like it. Some complained that they couldn’t find their applications.
3) Reliability. Installing in a per-user location simply doesn’t work in some Windows enterprise configurations.
4) Administrative Support. In many enterprises, admins do not want applications that install without admin privilege, as this is seen as an attempt to work around deliberate install restrictions.
One final note: We agree that you shouldn’t trust an AIR application any more than any other application. This is why we, in our install dialogs, warn about the dangers of installing any application that doesn’t come from someone you trust.
regards,
Oliver Goldman
Adobe AIR Engineering