[buildd-tools-devel] schroot

[Geoffrey Thomas]

On Tue, 8 Oct 2013, shawn wilson wrote:

> This is at the top of every schroot config file, but I can't find it 
> documented:
>
> . "$SETUP_DATA_DIR/common-data"
> . "$SETUP_DATA_DIR/common-functions"
> . "$SETUP_DATA_DIR/common-config"
>
> Where is this being sourced from (ie, where is the 'common-data' file?) 
> and (more important) where is this documented?

I can't seem to find documentation, but `git grep SETUP_DATA_DIR` inside 
the schroot git tree finds me these matches (as well as all the setup.d 
files, and one match in the Makefile generation):

sbuild/sbuild-session.cc:1090:  env.add("SETUP_DATA_DIR", SCHROOT_SETUP_DATA_DIR);
scripts/global.mk:53:-DSCHROOT_SETUP_DATA_DIR=\"$(schroot_setupdatadir)\" \

So it's exported into the environment in the session class out of a C 
preprocessor macro, which is in turn defined by the build process. In 
particular it seems to end up being /usr/share/schroot/setup on Debian.

`dpkg -L schroot | grep common` is another way to answer this.

> Also, maybe not an issue with schroot, but when I try to strace it, it
> won't authenticate where this otherwise works (yeah, I'm trying to
> figure out what those variables do without digging through source -
> probably stupid not to just look at the code but whatever):
> % strace -f -s 1024 -e trace=stat64,read,write schroot -c test -- ls
> / 2>&1 | tail -5
> write(2, "E: ", 3E: )                      = 3
> write(2, "PAM error: Authentication service cannot retrieve
> authentication info", 69PAM error: Authentication service cannot
> retrieve authentication info) = 69
> write(2, "\n", 1
> )                       = 1
> +++ exited with 1 +++

schroot is setuid root, so that it can run the chroot syscall for you, and 
it's responsible for checking whether you're authorized to do that. strace 
uses ptrace, a debugging facility, which is not allowed for setuid 
applications to prevent you from reading or writing privileged data (an 
obvious attack here would be using a more full-featured debugger like gdb 
to bypass the authorization check).

If this is your own machine and you have root, there are some workarounds 
that I've used when debugging setuid executables (I think including 
schroot) in the past. You can just run everything as root, which should 
work for your current use case but isn't a great general-purpose answer. 
You can attach to the process later with `sudo strace -p <pid>`; pausing 
the process with Ctrl-Z might make it easier to catch it before it exits, 
but also not a great general-purpose answer. Finally, you could try some 
contortion like `sudo strace sudo -u $USER schroot -c test`, or similarly 
with su.

-- 
Geoffrey Thomas
http://ldpreload.com
geofft at ldpreload.com