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
database.
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
stay.
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.
>>>+_VURPMI="$SBINDIR/urpmi"
>>
>>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'
wrapper.
A plain 'urpmi --root /vserver/...' is dangerous and must never be used.
Enrico
Footnotes:
[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
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver