[arch-general] RPM Question

[Dan Vratil]

----- Original message -----
> On Oct 3, 2010, at 4:59 PM, "Dan Vrátil" <vratil at progdansoft.com>
> wrote:
> 
> > 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.
> 
> If you want to be sure it can't escape, you could try using LXC to
> contain the fedora system.
> 
> It is a recent kernel technology designed specifically for this
> purpose, and has tools to build fedora amongst other distributions.
> 
> Very easy to set up a containerized system.
> 
> C Anthony [mobile]

Hmmm the LXC looks like a pretty cool project, that's exactly what I was looking for some time ago, thanks for bringing it in.

But if I understood correctly, you need to have entire system installed inside the container, which is I think a waste of diskspace for just one program, meanwhile chroot would require just default libs, bash and dependencies of that app.

Dan