Dropbear

Tag: Programming

  • Unlucky sometimes

    Sometimes life throws little curves at you to see if you are still awake, today has been one of those days.

    fglrx is (apparently) fixed

    I’ve had a long-running problem with fglrx on my laptop.  The problem stems from ATI closed-source drivers with one of those laptops that has an ATI and Intel driver. It means I am basically using the slow Intel chip only.  This morning I had enough and backed up my home and started to rebuild the laptop with Debian 6.0.3.

    So I kicked off the very very slow process of reformatting the crypto drive (it has taken 5 hours and still going) let it gurgle on its merry way and started to read my email.  One of the  emails was that my bug about fglrx not working is closed, apparently it is fixed.  If I had read that 10 minutes earlier, a simple ‘apt-get install fglrx-driver‘ would of perhaps fixed it; oh well.

    My problem is now is do I move to the latest driver and hope their fix is my fix or leave it with some ancient version?  My preference is the former; I only hope it works!

    psmisc 22.15 and buffer overflows

    psmisc has a program called pstree which prints the set of processes in a tree fashion.  It hasn’t changed much for quite a while.  I released version 22.15 and the Debian package 22.15-1.  22.15-1 I also adopted the harden CFLAGS as suggested for procps.

    I was a little surprised that I received an important bug.  The report was saying I had a buffer overflow introduced in 22.15-1, but no relevant code had changed.  The compiler options had done their job and stopped a buffer being overflowed.

    But where exactly was the overflow?  Running gdb on pstree quickly showed that it was line 267 of pstree.c which uses strcpy().  That function set off warning bells. The relevant code is:

        PROC *new;

    if (!(new = malloc(sizeof(PROC)))) {
        perror("malloc");
        exit(1);
    }
    strcpy(new->comm, comm);

     

    Now comm is the short command name you find in /proc//stat.  It is fixed in the kernel at 16 characters.  The PROC structure has this field as 17 characters long, one extra for the NUL.  I went and checked the Linux source and yes, it is still 16 characters long.  The clue was in the name of the program that it died on.

    #6  new_proc (comm=0x6111b0 "{console-kit-dae}", pid=1571, uid=0)
    at pstree.c:267

     

    That string is 17 characters long. The problem is that 16 characters is for the name only. If the name is in brackets or braces, then that 16 character limit doesn’t apply.  The buffer overflow bug has been there for a long time, but only with the compiler flags did it become visible.

    Given you need to read names out of the /proc filesystem and if someone can fiddle with that you have bigger problems it doesn’t seem to be too much of an issue.  It should be (and is in Debian 22.15-2) fixed but is a nice example of the compiler catching bad things.

     

    Related articles
    Enhanced by Zemanta

  • When a dynamic library and program share functions

    This is about making procps have a proper library but it really is a generic sort of question.  Say you are making a library and a program that uses that library.  Now at times you may have convience type functions; procps has them for things like escaping command names or allocation different sorts of memory.  Both the library and the programs use some of these functions.

    Now, there seems only two approaches to this setup.  The first is to have the function stay in the library and for the program to call this function, just like all the other library functions.  But this means the library has exposed for all other programs that link to it and that doesn’t really make a lot of sense.

    The second method is to have the functions defined in both places, perhaps in a file that is linked with the program and the library.  That seems to be duplicating the code in two different places.  Namespace collision could be a problem but that easily fixed with using some unqiue prefix.  I really don’t think having procfs_malloc, procfs_calloc and procfs_strdup are that useful.

    I’m sure this sort of problem has been solved elsewhere.  Has anyone else come across this? The functions are simple utility type functions such as malloc a block of memory, if there is a problem print to stderr.

     

    Enhanced by Zemanta

  • First Look at Python

    When the programming language Python came out while it seemed like an interesting idea, I didn’t really see the point. I already know Perl, PHP and C (plus a few others) why learn another language? So until recently, I didn’t

    Recent frustrations with PHP and how “loose” it is with things like variables made me have another look at Python and what it could do for me.  As just learning a language by itself it pretty boring I decided to write some small programs in the language and used the framework Turbogears to do it.

    First of all, learning the basics of python from perl or PHP is dead simple. The idea of what a language looks like is not too different between these three so it was a snap to write simple stuff in python.  So, what does yet-another language give me?

    • Variables must be defined before being used, but assigning them defines them too.  This is a nice compromise between PHP where you can check undefined variables and C where it all must be defined first, or else.
    • try and except. For code that might fail, use try and then catch the error in except.  We’ve all been guilty of using the @ symbol in PHP to supress stupid error messages, this does it correctly.
    • No PHP extract() or compact(). Actually just no extract function is good enough. That function is pure evil.
    • Sqlalchemy – A proper “you look after the database and ill play with objects” database extraction layer thingamy.  I don’t want to play with databases just let me write code and thats what sqlalchemy does well.
    • Testing – Turbogears uses nosetests which does functional and unit testing. I do get some annoying artifacts based upon testing but generally its all good.
    • Python has help() everywhere and pydoc on the command line. Not sure what variable foo can do? Just type “help(foo)” or even stick it in your script.
    • paster! You can run a development site off the command-line using a simple sqlite database. Don’t like it, dump the DB and reinstall it with one command.

    It’s not one-way though, there have been some challenges.  Quite likely these are more my deficiencies than the languages.

    • Error messages take up a whole screen and often make it difficult to isolate. It’s not quite 10-screens-full ala Eiffel but sometimes the error messages tell you something is going wrong, but not what. Mess up your object versus database table references and you get something rather obscure.
    • When is an integer not an integer? The answer is, sometimes. Sometimes they work, sometimes they break. It’s probably more to do with what pysnmp is doing with them.
    • Documentation – some is great, some is downright misleading. It comes down to the writer of the documentation for modules. At least it doesn’t have ‘well get round to it’ like some functions in PHP on their website. Documents that say you can directly iterate dictionaries were another dead-end I wandered down. If you are stuck here, add a .items() at the end of it.
    • Deployment. It’s not just a matter of taring the files up and sticking them into /var/www/sitename and you’re done.  There are probably good reasons why, but its just annoying.

    Despite the minor problems, python really does give you much much more than PHP and some more than Perl.  For me and what I am intending on writing it is worth learning yet another language.

    Related articles
    Enhanced by Zemanta

  • psmisc 22.14 Released

    The upstream and Debian packages for psmisc version 22.14 were released tonight.  This version has a lot of bugfixes.  I’ve also taken some time to clean up some of the minor compile warnings I used to get which were mainly variables set but not used.

    Two bugs that I’ll concentrate on getting fixed for the next version are all about the command line.

    The first is that the fuser -s flag changes the return code for items found.  It should be consistent so it doesnt matter if fuser displays values or not, 0 means found something and 1 means didn’t find it. I can see why in the code it might be different, because the code follows different paths with the s option, but not exactly where the problem is.

    The second bug is the -M flag for fuser only works if it is before the mount points so -M -m /foo works but -m /foo -M does not.  Unlike the -s problem, I can see where it is failing.  Currently fuser scans the options one by one.  If it finds a -m option, it checks at that point if the -M option is set.  The solution is to store all potential targets and only after exhausting the entire command line do we add the potential targets  to our “real” targets.  It means scanning the command line, or a subset of it, twice but the performance penalty is tiny.

    Finally, I released there was a rather neat Makefile command “make distcheck”. This target makes a tar.g archive, extracts it, builds then cleans.  It is a very good program for trapping things like a file exists in your local directory but is not included in the tar.gz (lists.h was missing until I ran this).  For some “make distcheck” is something they’re known for years, but if you have an autotools package you develop, have a look at it.

    With all the talk about testing and test driven releases, I was going to put some test cases in. The problem is there doesn’t seem to be an easy way to do testing. I might have to just hack up some scripts but surely there is a better way. That would trap, for example that fuser -s returns 1 but fuser returns 0.  I looked at check, but it doesn’t work for single-file programs like psmisc is mainly made of.

    Enhanced by Zemanta