Programming blindness and security
Here is a thought and a theory that has recently struck me.
One reason that writing secure programs is hard is because programmershave a kind of blindness about our own code. Instead of seeing the codeas it really is, we tend to see the code as we imagine it in our heads,and as a result we see what we wrote it to do, not what it actuallydoes.
(This is not usually a literal blindness, although we can do that too,but a disconnect between what the the
Environment variables make bad switches
Someday you may be faced with a deprecation situation where you need to add a compatibilityswitch to your program. When in this situation it may be tempting toresort to controlling things with an environment variable, instead ofgiving your program yet another command line option.
(The problem with using command line options is that they add clutter,complexity, or both to your documentation, including any usage stuffthat the program prints.)
Unfortunately this is not a good way to add such switches to yourprogram, especially compatibility switches
The IO scheduler improvements I saw
In the spirit of sharing actual numbers and details for things that I lefta bit unclear in an earlier entry , here is more:
First, we switched to the deadline IO scheduler (from the default cfq ). I did brief tests with the noop scheduler and found itbasically no different from deadline for my test setup, and deadline may have some advantages for us with more realistic IO loads.
My IO tests were sequential read and write IO, performed directlyon a test fileserver , which usesa single iSCSI backend
How to deprecate bits of your program
Since this appears necessary , here is how todeprecate some bit of your program in a way that makes sysadmins hateyou as little as possible.
- first, add a warning to your documentation and a 'compatibilityswitch' that causes your program to use the old behavior that youare deprecating. Of course, the compatibility switch currently doesnothing since the old behavior is the current behavior, but nowyou've let people start explicitly specifying that they need theold behavior.
If you are changing the behavior of your program
Some more thinking about requirements in specifications
Aristotle Pagaltzis 's comment on my previous entry prodded me into doing somemore thinking about this, and his entry on RFC 2119 usage has persuaded me that thereare actually four degrees of requirements that it's useful toput into specifications.
Put simply, I'd say that they are:
- allowed: you can do this, and some people will (so be prepared to copewith it).
- recommended: we think that you should do this.
- should: not doing this causes problems for
MUST versus SHOULD in your specifications
Something I've been mulling over lately is the the effects of A rulefor Internet software on specifications and how strongyou make requirements in them.
To put it one way: a 'MUST' in a specification makes a handy club tobeat people with, but perhaps they are best reserved for things thatare absolutely required in order to make the protocol work, becausein practice that is what is going to happen anyways.
(Note that a MUST often does not make an effective club, because ifit doesn
ZFS changes filesystem device numbers on reboot
Here is an unpleasant discovery that we just finished making: in atleast Solaris 10 U6, ZFS changes the device numbers of all of yourfilesystems when your system reboots . More specifically (and evenworse), the device numbers of a pool's filesystems change wheneverthe pool is imported, including the implicit import that happenswhen a system boots up.
(This raises interesting questions of how NFS filehandles keepworking across system reboots, which they do. Presumably theyhave some other stable identifier for a given
What packages SystemTap requires on Ubuntu 8.04 (and others)
For my own future reference and because the SystemTap wiki is not the clearest thing onthis, here's what packages are required to be able to use SystemTap onvarious distributions.
We use the -server kernels on our Ubuntu 8.04 machines, so I neededto do:
apt-get install systemtap linux-image-debug-server linux-headers-server
ln -s /boot/vmlinux-debug-$(uname -r) /lib/modules/$(uname -r)
A frame object's f_locals isn't always the locals
Python frame objects have a tempting member called f_locals , whichis described as the 'local namespace seen by this frame' (to quote the inspect module ). This isslightly misleading, because it is not always what Python programmersnormally think of as 'locals'.
Specifically, if the frame comes from code that is running at themodule level, f_locals is the 'local namespace' of that code,that is, it is the module's namespace. In other words, it'
The problem with the CFQ IO scheduler and our iSCSI targets
Current versions of Linux have several different waysto schedule IO activity; one writeup of this is here .The developers of the iSCSI target software that we use have for some time recommended that peopleswitch away from CFQ (the default one) to either the 'deadline' or the'noop' scheduler to get better performance. Recently I got around totesting this to see if it made a difference in our environment, and itturns out that it does.
(Whether the difference is significant is an open question.