Linux installing applications requires root password.

Question

Can anyone explain to me why it is that on Linux, Air
requires a root password to install an application even if the
installation directory is specified as somewhere within my own home
directory?
That it asks for a root password under such circumstances
seems very wrong. The application files are being written to my
home directory, I don't need to be root to write there and I do not
want files being created in my home directory with root as the
owner, as Air does when it installs an application.
Asking for the root password also means that users who have a
Linux machine that is administered for them by someone else and do
not have root are unable to install Air applications themselves
even if the administrator has installed Air on their
machine.

Answer 1

First of all, on behalf of myself (and anyone else who has
been wondering about this particular detail of Adobe AIR) let me
thank you for your helpful reply. This does still leave me with a
couple of questions, however...
quote:
Originally posted by:
Ashutosh Sharma
AIR applications are similar to regular native applications -
they install as native rpm/deb packages. This requires access to
the rpm/deb system database (e.g. rpm database lock). And this is
required even if the installation folder is chosen to be one that
is owned by the current non-root user. In addition, with root
privileges, it's also possible to install applications to a
location that is accessible to other users on the system.
I have confirmed for myself the accuracy of this information
and I thank you for pointing it out. While this does make some
sense on the surface, it does leave me wondering something about
the security level of this install process. When I install
applications from my Linux distribution's package sources, I have
GPG (or PGP) cryptographic key signatures ensuring that all the
packages are un-altered from their original form on the
distribution's package servers, and a team of programmers assuring
me that the code of these packages are (at least somewhat) safe as
far as they are able to tell. I am thus far unable to find
information leading me to believe that there is similar assurance
that I am not willingly installing unknown malware (keystroke
logger, spyware, etc.) disguised as a desktop widget (for example)
when installing Adobe AIR applications. As a code savvy user, I can
personally download and examine the code of many AIR apps to ensure
their safety myself before installing, but what about users who
understand code as well as they understand Martian language or
ancient Egyptian hieroglyphs? Is there any assurance process in
place for the average user similar to that of native distro
packages? If so, can anyone point me to where that is discussed on
the Adobe pages?
Also, as an aside note; root privileges are not technically
REQUIRED in order to install an RPM package in a location which the
user already has write access to, as I personally have on many
occasions installed source code packages (SRPM) from my
distribution's package manager in my home folder while logged in as
a normal user (without the use of 'su' or 'sudo' or such) for the
purpose of building newer versions of the RPM packages which they
correspond to.
quote:
Originally posted by:
Ashutosh Sharma
However, do note that when they are launched, AIR
applications run with the privileges of the user launching the
application and not root. The primary executables of AIR
applications (under the bin/ folder in the installation path) do
not have the setuid bit set. You should not be worried about AIR
applications running with root privileges, based on the fact that
their installation required superuser access - the two are
completely independent.
This does still go back to the original point about the
security of the code itself which is being installed in the first
place. What quality assurance process is in place (beyond the star
ratings system on the application showcase site) to ensure that
malware was not installed (as root) and then happily being run by
all the users of a system while blissfully unaware of the capture
of their passwords or other personal information? (Again, an
example, and not the only such possible worry.) If such an
assurance system
is already in place, where can I (and other AIR users) read
more about it?
The reasons for this concern should be obvious when one
considers that a malicious application does not necessarily need to
be run as root to still do a great deal of damage on a system and a
sufficiently sneaky malware application could possibly even
obtain root privileges once installed on a system through
some other privilege escalation exploit. As an administrator of
multiple systems and networks, I have to be cautious about which
applications I allow on to a system or network for this very
reason.
Please be aware that I am not making these points and asking
these questions to be a "troublemaker" or to shoot down the
achievements of the AIR team, or Adobe. To the contrary, I am very
impressed by the technology that I've seen so far and would
very much like to see AIR become and stay a genuinely useful
part of the web ecosystem on all platforms. As a matter of fact,
I'm personally reading a few different resources currently about
how to develop AIR applications in anticipation of satisfactory
answers to my few remaining concerns about AIR security worries. ;)
P.S.: If this forum was the wrong place to be discussing
these specific types of issues and concerns, please feel free to
point me toward a better place where such things should be better
covered and where like-minded individuals and groups might either
continue the discussion or resolve / close this concern entirely.
An IRC channel where AIR devs hang out maybe, or perhaps another
Adobe forum where security concerns are discussed, etc.? :)
Anyhow, sorry about the long rambling post. Thank you to
Ashutosh Sharma for your initial reply to this thread, and thank
you in advance to whoever may reply further and bring final
resolution to any remaining worries I and others may have regarding
these and similar potential security concerns. :)