Tagged with Programming

Python Exception Chaining

OpenStack has an awful lot of developers writing Python code and many of us wouldn't consider ourselves true "pythonistas". This means we wind up having a bunch of interesting discussions about e.g. EABL vs LBYL.

A particular bugbear of mine is exception handling. I'm convinced that very, very few developers think hard about their error handling strategy and that the problem is even more serious with exception based languages.

So, I really like getting into error handling discussions. This morning, we have a great one - how to do exception chaining in Python, and whether that's even something you want to do.

Tagged , ,

Error Handling

I came across a fairly typical error handling mistake today and thought I'd share it.

The code was something like this:

class Factory {
    static Foo getFoo() {
        try {
            // load a .properties file, read a key from it
            ...
            return new Foo(propValue);
        } catch (Exception ex) {
            log.error("Failed to find key in properties file: " + ex.toString());
            return null;
        }
    }
}

and the caller did e.g.

    Factory.getFoo().doSomething();

The thing to note here is that the caller is assuming that getFoo() method never returns null.

That's probably a good assumption on the part of the caller. The factory method should always succeed unless there is a programmer error (e.g. the key does not exist in the .properties file) or a system error (e.g. an I/O error accessing the file). Neither of which the caller should be expected to handle gracefully. That's what exceptions are for!

In the event of an error, we'd get a NullPointerException from the caller site and an error printed to the logfile. If, for example, you are running this code in a debugger, you'll be looking at a NullPointerException with no clue as to what caused the exception.

The moral of the story here is to think clearly about when errors should be handled gracefully and when you should just let exceptions be passed back up the stack.

In the end, I added a new exception type:

class FactoryException extends RuntimeException {

    private static final String ERROR_MSG = "Failed to lookup key {0} in file {1}";

    private String propsFile;
    private String propsKey;

    FactoryException(String propsFile, String key, Throwable cause) {
        super(MessageFormat.format(ERROR_MSG, propsFile, key), cause);
        this.propsFile = propsFile;
        this.propsKey = propsKey;
    }

    String getPropsFile() {
        return propsFile;
    }

    String getPropsKey() {
        return propsKey;
    }
}

and then re-factored the original code:

class Factory {
    static Foo getFoo() {
        try {
            // load a .properties file, read a key from it
            ...
            return new Foo(propValue);
        } catch (Exception ex) {
            throw new FactoryException(propsFile, propsKey, ex);
        }
    }
}

so now if there is an error, rather than getting a fairly useless NullPointerException you get:

FactoryException: Failed to lookup key foo in file bar.properties
    ...
Caused by: java.io.FileNotFoundException: ...
Tagged

Stack Guard Page

The most interesting little tidbit I learnt from the memory usage
debugging yesterday was
about the "stack guard page". Look at this bit in the strace:

mmap2(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7219000
mprotect(0xb7219000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb7c194c4, flags=CLONE_VM|...) = 2282

What's going on here is that libc is mapping an area for the thread's
stack, just before spawning thread. The interesting bit is that, using
mprotect(), it also changes the permissions on the first page
(the page at the top of the stack) such that any instruction which
attempts to write to the page will cause a segmentation fault.

That's your stack guard page; it means that your infinitely recursing
function won't go off an scribble over its neighbouring thread's stack,
it'll just segfault like a good little thread.

(In true pthreads tradition, you can even configure the size of
this guard area - see the pthread_attr_setguardsize() manpage)

Tagged ,

Runtime Linker Voodoo

Kjartan pointed out a report of a gnome-session security vulnerability
to me earlier today. Now, it turns out to actually only be a
vulnerability in a script supplied with certain distributors' packages,
but that's not the interesting part.

The script contained something like this:

  export LD_LIBRARY_PATH=/opt/gnome/lib:$LD_LIBRARY_PATH

and the "vulnerability" was apparently that if \$LD_LIBRARY_PATH
was originally unset, then you get
LD_LIBRARY_PATH="/opt/gnome/lib:".

I couldn't for the life of me understand why it was actually a
vulnerability in the first place. It gnawed at me all day. After a bit
of poking at the runtime linker code in glibc though I realized that
setting \$LD_LIBRARY_PATH like that is effectively the same as
setting it to LD_LIBRARY_PATH="/opt/gnome/lib:./". The problem is
clear then - an attacker can use it to force a rogue, untrusted
library to be loaded that could do nasty things.

So, this whole LD_LIBRARY_PATH=":" causing "./" to be added to
the runtime linker's search path thing came as a big suprise to me and
to some others. I'd never heard of before, but it seems known to at
least some people and is "expected behavior". What worries me here is
that its likely most attackers know to look out for this and most
developers don't.

My long search for a normative reference for this behaviour failed. If
anyone knows where it comes from, I'm dead curious. I expect Ulrich
knows, though :-)

Another interesting thing to play with:

$> LD_DEBUG=help /lib/ld-linux.so.2
Valid options for the LD_DEBUG environment variable are:

  libs        display library search paths
  reloc       display relocation processing
  files       display progress for input file
  symbols     display symbol table processing
  bindings    display information about symbol binding
  versions    display version dependencies
  all         all previous options combined
  statistics  display relocation statistics
  help        display this help message and exit

I read a paper
from Ulrich
some time ago that gave lots of details on how to write
shared libraries such that the runtime linker can more efficiently
resolve symbols etc. LD_DEBUG=statistics, among other things,
is useful there. I'd love to see someone with the time and interest
looking into this and analyzing GNOME libraries to see where we can
make improvements.

Tagged , ,

Voodoo

I hate now knowing how things work. Especially things that I
rely on heavily as a hacker. But I love it when I get a chance
to finally figure out how the damn thing works and it turns out
to be beautifully simple.

This week I found that I had to debug a small part of libtool's
behaviour. It had always worked for me before and I had assumed
it worked a certain way, but in this case it just wasn't
working properly. I could feel myself breaking out in a cold
sweat. Don't make me debug libtool! Please God, noooo...

But the clouds parted. And it was simple.

When you build an executable, and it links against a library
in the same module, you need some way to be able to run that
uninstalled executable with the uninstalled library. So,
libtool puts a script where you think your uninstalled
executable should be and here's what it does

  • When you run the script for the first time, it re-links
    your executable with --rpath $path-to-lib/.libs and
    places that executable in .libs/lt-myexec.
  • That causes the linker to to put a DT_RPATH ELF
    attribute in the executable which tells the dynamic loader
    where to looks for libraries. (See the ld.so manpage)
  • And finally, the script just runs the modified executable.

For example:

  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  $> ./gdk-pixbuf-csource
  Usage: gdk-pixbuf-csource [options] [image]
  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51294 Feb 28 15:48 .libs/lt-gdk-pixbuf-csource
  $> objdump -p .libs/gdk-pixbuf-csource | grep RPATH
  $> objdump -p .libs/lt-gdk-pixbuf-csource | grep RPATH
    RPATH       /gnome/head/cvs/gtk+/gdk-pixbuf/.libs:/gnome/head/INSTALL/lib
  $> ldd .libs/gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/INSTALL/lib/libgdk_pixbuf-2.0.so.0 (0x0087d000)
  $> ldd .libs/lt-gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/cvs/gtk+/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so.0 (0x004a0000)

Not exactly, earth shattering. But nice to know.

Tagged ,