[buildd-tools-devel] sbuild: retrieving schroot mount point

Johannes Schauer j.schauer at email.de
Wed Jun 4 21:28:04 UTC 2014


Hi,

Quoting Roger Leigh (2014-06-03 23:58:05)
> Not at the moment.  However, fixing this has been desired for some time--
> the existing hooks could be expanded in scope fairly easily; they do need
> defining a bit more clearly though so it's clear what privileges each
> hook has, and if they are accessible to end users or not (i.e. if they
> run as root or as the sbuild user, and if they are run inside or outside
> the chroot).

indeed. For example I was surprised when I read in the sbuild source that the
post-build-commands only fire after a successful build and not otherwise.

> > If this doesnt exist yet, would you accept a patch implementing it?
> 
> Absolutely, that would be really appreciated.

just to scratch my current itch, I would need a hook which fires exactly before
and exactly after the actual package build. Would I use the existing hooks to
trace file access, then they would also capture package installation and the
build directory setup. It would be hard and probably error prone to filter out
these types of filesystem accesses from any resulting log.

Attached patch does what I want but please do not consider as as a suggestion
to be implemented. But since code says more than 1000 words, this is something
that would solve my current problem.

> However, there may be issues tracing since we won't necessarily have root on
> the host, only in the chroot.  And since schroot is setuid that will prevent
> ptracing in the chroot.  It might be possible to do entirely inside the
> chroot though?  Non-ptrace mechanisms might be fine though.

I am currently using fatrace because it turned out to not slow down the package
build at all in my tests. Using strace for example resulted in a 2-3 times
slowdown. But fatrace also needs root because it uses fanotify.  In the worst
case I can just do the building on a local machine where I can have root.

My current solution using fatrace and the attached patch uses a fifo in the
mounted /home directory to communicate information from within the chroot to a
script outside the chroot which does the tracing. The location of the chroot is
important so that fatrace can restrict its tracing to the mounted tmpfs.

I first start the following script on the host:

	#!/bin/sh -x
	mkfifo /home/josch/myfifo
	SCHROOT_SESSION_ID=`cat /home/josch/myfifo`;
	cd /var/lib/schroot/mount/$SCHROOT_SESSION_ID;
	fatrace --current-mount > fatrace.log &
	FATRACE_PID=$!;
	cat /home/josch/myfifo > /dev/null;
	kill $FATRACE_PID;

And then I run sbuild like this:

	sbuild --pre-realbuild-commands='/home/josch/prerealbuildcmd.sh' --post-realbuild-commands='/home/josch/postrealbuildcmd.sh'

Where /home/josch/prerealbuildcmd.sh contains:

	#!/bin/sh -x
	echo $SCHROOT_SESSION_ID > /home/josch/myfifo

And /home/josch/postrealbuildcmd.sh contains:

	#!/bin/sh -x
	echo "done" > /home/josch/myfifo

While hacky, this seems to do what I want and I get all file accesses in
fatrace.log for later evaluation.

On the other hand, if this doesnt sound too whacky, then I could spend some
more time to prepare a patch which implements the *-realbuild-commands
properly. For example I didnt manage to come up with a good name for a hook
name around the actual build as *-build-commands is already taken but includes
the whole setup and teardown process as well.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-pre-realbuild-commands-and-post-realbuild-comman.patch
Type: text/x-diff
Size: 3008 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20140604/85be6a6a/attachment.patch>


More information about the Buildd-tools-devel mailing list