[arch-general] RPM Question
wolfgang at sweet-haven.com
Sun Oct 3 17:21:28 EDT 2010
On 10/03/2010 01:29 PM, Dan Vrátil wrote:
> On Sun, 03 Oct 2010 12:19:30 -0700, Lew Wolfgang
> <wolfgang at sweet-haven.com> wrote:
>> On 10/03/2010 11:11 AM, Dan Vrátil wrote:
>>> On Sun, 03 Oct 2010 09:00:08 -0700, Lew Wolfgang
>>> <wolfgang at sweet-haven.com> wrote:
>>>> On 10/02/2010 06:10 PM, Steven Susbauer wrote:
>>>>> On 10/2/2010 7:41 PM, Lew Wolfgang wrote:
>>>>>> It works on all the major distros but fails to install
>>>>>> on Arch due to an RPM dependency. Their install script just fails saying
>>>>>> it can't find rpm. The script contains much ugliness and is McAfee
>>>>>> proprietary, so I doubt hacking it will be productive.
>>>>>> So the question is: can Arch be configured/tricked into an rpm install?
>>>>> Does their installer actually require use rpm to install, or just wants rpm to be> there? Most distros allow you to install rpm, Arch is no different except it is in> aur:
>>>>> aur/rpm 5.2.1-1 (153)
>>>>> The RedHat Package Manager. Don't use it instead of Arch's 'pacman'.
>>>>> If it actually uses rpm for the process, this is probably not the solution. Two> package managers at once is not a good thing.
>>>> I spent some time last night pulling the .sh file apart. It's a
>>>> script that unzips a binary that unpacks two rpm files (9-MB), one
>>>> 32-bit ELF program (8.9-MB), two cryptographic keys and an xml file.
>>>> The script then calls rpm to install the two rpm files, which contain
>>>> tons of 32-bit system libraries. These libraries have the same names
>>>> as regular system libs, like libc, libm, libresolv and libcrypt. This
>>>> all makes me very nervous! Arch not using rpm may be a blessing in
>>>> disguise, I'm going to see if I can get a waiver to not install this
>>>> McAfee root-kit.
>>>> Thanks for the help,
>>> What about setting up a simple tiny chroot just for this application?
>> That's an interesting idea, Dan. But since this package is supposed
>> to install itself like a cancer in the OS, it wouldn't be able to
>> perform its function in a chroot. The Windows version of this thing
>> is intended to remove local administrative privileges so that the
>> machine can be completely managed remotely. It can prevent unapproved
>> programs from being loaded, and can disable installed programs that it
>> has an issue with. Indeed, it disabled non-current versions of Adobe
>> Acrobat a couple of weeks ago. It also has an IPS function to monitor
>> and disable network traffic it finds threatening. It can enforce
>> password polices and can report what a user is doing and what web
>> sites they're visiting. It can sniff network configurations and
>> report dual-homed hosts, natted subnets are also disallowed. I'm
>> sure it does much more. I've been told that the Linux/Apple versions
>> only report at this time, the more intrusive capabilities aren't yet
> Well it is just an application, not a kernel module or so, so in my
> it does not matter if it runs in chroot or not, as it can only obtain
> from some /proc, /sys and /dev files and these can be made available
> in the chroot via mount (e.g. by mounting the real folders to the
> What I want to say is, that the application can have access to all the
> it wants, but it will just be installed separately from your beloved
Interesting. I wonder how one would do this? Since the package depends on RPM,
could that be installed in a jail and not interfere with pacman? Or would most of a
second OS need to live in the jail? Can you install a full-up Fedora or openSuSE in
a jail? The jail would need access to the main /etc/passwd and /etc/shadow files,
wouldn't that be rather difficult to set up? A chroot that has full access to /?
Interesting to contemplate...
More information about the arch-general