[PATCH] Added 'rpm-dbpath' option; enhanced chroot operations

[Rehan Khan]

Imported: http://tracker.labix.org/issue63

Reason:Review Issue. Is this stalled because it is really an issue in rpm?

further details: https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration

msg203 (view) Author: ensc Date: 2006-01-02.19:16:37

I can not change the dbpath outside the chroot because rpmlib does not support
dbpaths outside of the chroot.

The patch is necessary because smart is doing insecure operations. You CAN NOT
emulate a chroot environment just by concatenating two paths.

E.g. old smart code did

| tmpdir = os.path.join(getTS.root, "var/tmp")
| os.makedirs(tmpdir)

When '<chroot>/var' is a symlink to /etc, then /etc/tmp will be created outside
of the chroot.

Or

| path = os.path.join(sysconf.get("rpm-root", "/"),
| "var/lib/rpm/Packages")
| digest = os.path.getmtime(path)

When <chroot>/var/lib/rpm is a symlink to somewhere else (e.g. linux-vserver
makes it a symlink to /.rpmdb by default), the wrong 'Packages' file will be read.

This patch fixes the chroot handling in smart but it can not fix/change the
handling in rpmlib.

msg199 (view) Author: netmask Date: 2006-01-02.19:02:28

Maybe you could change the dbpath outside the chroot if you don't do a 'real'
chroot as you did on your patch (sys.chroot).

Sorry if I'm a bit lost here, but if you can't put the dbpath outsite the
chroot, I don't see the real necessity for the patch you suggested.

The current chroot implementation in Smart in fact passes the rpm-root option to
the rpmlib to handle, so I don't see how it could break something if rpm has
been doing that for ages. IIRC when you pass the root directory to the rpmlib
all the '/' operations actually happen inside the root passed.

msg193 (view) Author: ensc Date: 2005-12-30.15:33:59

It would be nice when I could store it outside of the chroot (and it would be
easy to do it for the 'smart' part). But rpmlib does not allow this, so
'rpm-dbpath' sets the dbpath *inside* the chroot.

It should have the same effect like setting '%_dbpath' in /etc/rpm/macros.

The patch just ensures that:
* chroot functionality (e.g. symlinks to '/...') will not be broken by 'smart'
* the db-path can be configured

Btw, I am not sure if the initdb and /var/tmp part is really needed. rpmlib
seems to initialized the db automatically and I could not find another reference
to /var/tmp in the smart sources.

msg192 (view) Author: netmask Date: 2005-12-30.13:11:38

I'm not sure if I understand the correct usage here, but I did give it a shot:

# smart -o rpm-root=/tmp/tmp-root -o rpm-dbpath=/tmp/tmp-db install coreutils

Now I have a /tmp/tmp-root/tmp/tmp-db, which means it did change the dbpath, but
it saves it *inside* the chroot. IIUC, your intention was to save the rpm db
*outside* the chroot, isn't it?

I'm reviewing your code, and making some tests, but it's Gustavo who will decide
if it should be incorporated or not.

msg187 (view) Author: ensc Date: 2005-12-26.14:20:57

e.g. try

| # d=/tmp/foo
| # mkdir -p $d/var
| # ln -s /root $d/var/lib
| # smart -o rpm-root=$d update

--> it will create an 'rpm' directory in the host's /root directory. With some
other paths this might be used for attacks from within the chroot environment or
it might destroy functionality when such symlinks are used. And yes, secure
chroots are posssible; e.g. see Linux VServers, Solaris Zones or BSD jails.

'rpm-root' means "chroot". It's not possible to emulate a chroot environment
just by concatenating two paths (as in the current code). You have either to do
a real chroot(2), or a complicated chdir-by-pathcomponent walking.

msg185 (view) Author: netmask Date: 2005-12-26.13:57:58

Sorry, I could be missing something, but I don't get the issue here.

Using 'rpm-root' I'm perfectly able to get a chroot environment with proper
<chroot>/var/lib/rpm, completely independent from the main system.

Again, sorry, but I don't see what's the issue here... :(

msg182 (view) Author: ensc Date: 2005-12-26.11:54:37

This patch adds an 'rpm-dbpath' option which overrides the default
'/var/lib/rpm' location. To ensure proper 'rpm-root' operations, all
related operations will be executed after a 'chroot(2)'. So, attacks/nasty
surprises can be avoided when e.g. '/var' is a symlink to '/my-var'.

Unfortunatly, this patch does not honor an existing %_dbpath macro because
it seems to be impossible to expand macros with the rpm python bindings.

[Rehan Khan (rasker)]

If I understand this correctly both netmask and ensc are correct. rpmlib handles chroot's in an unsecure way and smart assumes the rpmlib way is correct. However the patch fixes Smart to not do things in an unsecure way even though rpmlib allows this behaviour. So this patch prevents Smart itself from following symlinks outside the chroot (a good security measure) although rpm or the rpm one is installing might be able to escape the chroot somehow (by following symlinks inside the chroot which point outside the chroot) which is something Smart cannot prevent. I would recommend this be considered for inclusion as a 'security feature' in Smart with the caveat that it does not fix rpmlib just stops Smart from behaving insecurely.