[arch-general] RPM Question

Dan Vrátil vratil at progdansoft.com
Sun Oct 3 17:59:02 EDT 2010


On Sun, 03 Oct 2010 14:21:28 -0700, Lew Wolfgang
<wolfgang at sweet-haven.com> wrote:
> 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

Actually that should not be so difficult to set up. You can use program
called "schroot". It mounts the real folder (/home, /dev, /proc etc) to
the
chroot using fstab-like file (see /etc/schroot/mount-arch32) and it
also
copies some essential files (like /etc/shadow and /etc/passwd) to the
chroot
(see /etc/schroot/copyfiles-arch32).

Additionally, I think you don't need access to full /, just to /etc,
/dev, /sys 
and /proc since that's all where the program can get any useful info or

where any essential data to be watched over are located. If I'm wrong, 
it's not a problem to mount the folder to the chroot filesystem.
The rest of the chroot's filesystem can contain whatever you want. 
Actually I believe that it should work even when you would have only 
the libs that the program is linked against and some applications that 
the program needs to run, you don't even have to install kernel, udev, 
etc.

I'd recommend not to even use pacman to set up the chroot, but use RPM
to set it all up from the main system, something like:

rpm install base-system --root=/home/chroot
--dbpath=/home/chroot/var/lib/packages
(I don't know how to use rpm, just to show the idea)

and then enter the chroot using

schroot -c my_chroot

and then just start the application from the chroot.

Dan

-- 
--
Dan Vrátil
vratil at progdansoft.com
Tel: +4202 732 326 870
Jabber: progdan at jabber.cz

Tento email neobsahuje žádné viry, protože odesílatel nepoužívá
Windows. /
This email does not contain any viruses because the sender does not use
Windows.


More information about the arch-general mailing list