[buildd-tools-devel] schroot

[shawn wilson]

Nice. Thanks. (esp the ptrace bit - I didn't know that but it makes
perfect sense)

On Tue, Oct 8, 2013 at 2:29 AM, Geoffrey Thomas <geofft at ldpreload.com> wrote:
> 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