About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Sun 20 Feb 2005 - 23:23:25 GMT

erwan_at_seanodes.com (Velu Erwan) writes:

>>I do not know if urpmi supports this, but it should be possible to
>>specify the version of Mandrake Linux. E.g.
>>| vserver ... build -m urpmi -- -d mdk10
> Of course it could be done, but the main idea was to install the
> vserver using the virtual basesystem rpm (available on all
> mandrakelinux release).

I have to admit that I do not know anything about 'urpmi', but with
'yum' and 'apt' I can configure the repository which is going to be
used. This makes it possible to install FC2 guests on FC3 hosts by using
'... -d fc2'.

So it would be nice when I could call 'urpmi' in the same way (install
mdk9 guests on a mdk10 hosts e.g.).

>>>- _rpmdb_mntpoint=/.rpmdb
>>>+ _rpmdb_mntpoint=$BASEDIR/.rpmdb
>>This does not look sane. The rpm-database mountpoint MUST be at the / of
>>the vserver.
> I must assume that some hack were introduce but certainly because I
> didn't catch everything in vserver's architecture.

Oooh... I just detected an ugly bug in the rpmdb handling which was
hidden by the /var/lib/rpm symlink.

Please try [1] if it fixes your problems. Else:

Base idea behind the external packagemanagement is, that host commands shall
never rely on any guest data. E.g. I do not trust db4 (the databasesystem
used by rpm) enough to store the rpmdb within the guest. Perhaps there are
exploits in the database-reading-code which can be triggered by a manipulated

So, using /var/lib/rpm as a place for the rpmdb is dangerous: an attacker
within the vserver could create a /var/lib -> /somewhere symlink pointing
to such a manipulated database. And there is nothing which can be done
against it...

That's why, the rpmdb has to be mounted into the toplevel directory
where such symlinks are impossible.

Using /.rpmdb is a hack; /dev would be a much nicer place because it
is available everywhere and ignored by rpm. But there is rh bugzilla
bug #106057 which requires that the rpm database must be both in the
chroot-environment and in the real-root one. So the /.rpmdb has to

The position of the rpm-database is specified by the %_dbpath macro
which is changed in the vserver specific rpm-configuration. I do not
know if 'urpmi' honors this macro (apt had a similar bug which caused me
to create an (insecure) /var/lib/rpm -> /.rpmdb symlink), whether it
must be configured at another place, or if 'urpmi' must be fixed.

>>path should be determined in %configure. And the variable should be
>>named '_URPMI', not '_VURPMI'.
> Once again a lake in the the global knoweldge :/

How will you operate after the vserver was build? Do you require an
'vserver ... pkgmgmnt internalize'? If not, you should create a 'vurpmi'

A plain 'urpmi --root /vserver/...' is dangerous and must never be used.


[1] http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/scripts/vserver-build.functions.rpm.diff?r1=1.5&r2=1.6

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sun 20 Feb 2005 - 23:24:03 GMT by hypermail 2.1.3