[arch-general] RPM Question

[Lew Wolfgang]

  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,
>>>> Lew
>>> 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
>> implemented.
>>
>> Thanks,
>> Lew
> Well it is just an application, not a kernel module or so, so in my
> opinion
> it does not matter if it runs in chroot or not, as it can only obtain
> datas
> 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
> chroot).
> What I want to say is, that the application can have access to all the
> informations
> it wants, but it will just be installed separately from your beloved
> Arch.
>
>
Hi Dan,

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...

Regards,
Lew