Hi, As discussed on the boat under DebConf, here's a patch to enable ccache support in pbuilder. I've only tested it lightly, but it seems to work well.
it ?
FWIW, the simple setup that just works(tm):
export CCACHE_DIR="/var/cache/pbuilder/ccache"
export PATH="/usr/lib/ccache:${PATH}"
EXTRAPACKAGES=ccache
BINDMOUNTS="${CCACHE_DIR}"
BTW, why not use CCACHE_DIR instead of CCACHE_LOCATION ?
Mike
The permissions get all wrong. I initially tried bind-mounting, but suddenly a random user from the outside can fiddle with your ccache. That is not a good thing. Feel free to change such aspects. :-) /* Steinar */
Hi, I don't think that's too much of a problem if the way ccache works is what I think it does. Looking at Steiner's patch, it's rather too big. Why not just provide the configuration file, and make a shorthand option for the configuration? I think it'd be better to follow existing documentation and name it accordingly. http://pbuilder.alioth.debian.org/#ccache regards, junichi
Could you outline your assumptions, please?
Well, if you change the {save,restore}_ccache to using bind mounts instead,
the patch _is_ almost just that. So I guess we agree :-)
/* Steinar */
Hi, ccache is supposed to do the right thing even when ccache data is shared inside/outside of chroot, right? Users can fiddle with your ccache and you should not be affected. There's a big difference between using already-existing --bindmounts feature through configuration file and adding a new function. regards, junichi
clone 430765 -1
retitle -1 SECURITY: Host user 1234 can tamper with build chroot
tag -1 + security
stop
I don't think ccache can detect this case; I think what Steinar is
saying is that e.g. /var/cache/pbuilder/ccache/**/* files will be owned
by the user from within the chroot used to build packages, typically
uid 1234, but this user might be a real (potentially malicious) user
outside of the chroot. This 1234 user on the host could change the
compiled data so that the next build using the ccache with the same
source would pick up a modified (and malicious) version.
I agree it's an issue, and I think pbuilder should create an user +
group on the host, and use the same uids in the chroots (e.g. "getent
passwd >$CHROOT/etc/passwd").
I think this is not a new issue though: the build also runs as guest
uid 1234 and a malicious host user 1234 could just as well write to:
/var/cache/pbuilder/build/<build-id>/tmp/buildd/<source-package-version>/
(i.e. to the build tree).
I just pushed a ccache support patch to pbuilder git; I'm happy to hear
feedback on this patch.
Thanks,