Comments on: Sloppy systems programming

By: Adam S

Adam S — Sun, 01 May 2005 15:43:10 +0000

Bad URL above, which Peter gave me while doing some updates. The correct link is http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

By: Chris Walsh

Chris Walsh — Sun, 01 May 2005 00:05:40 +0000

What is more awful, IMO, is that it says stat(2) failed, when it actually called lstat(2)!
I don’t know what log_err() does, but (again, IMO) failing and not saying why (perror() or “ARRRGH! Symlink detected!”) sucks.

BTW, I suspect that it refuses to follow the symlink in order to avoid a race condition (but nonetheless the existing code is still vulnerable to one). Misleading diagnostic output is never acceptable, however. It looks like they may originally have used stat(2) and then modified the code, but not the diagnostic output. Sloppy.

By: Adam S

Adam S — Sat, 30 Apr 2005 17:19:14 +0000

It apparently decides that this is fatal, because it knows more about the security trade-offs of your environment than you do, and that when it sees this policy violation it will fail and lie to you about why it failed.

Hi Zach!

First let me say, I’m in complete and total agreement with your analysis of why this is the wrong way to handle the issue of stat’ing a link. But as a security weenie, I recognize where the authors were coming from: Stating links is dangerous. The right fix, however is neither to die, nor to lie in your errors, but open the file, then stat the file descriptor. Peter Guttmann maintains code to safely open files in C, at http://www.cypherpunks.to/~peter/snapshot.zip in io/file.c So you dont even have to do the hard work. Now if only he’d chmod it properly. ;)

By: boolean

boolean — Fri, 11 Feb 2005 14:17:32 +0000

pps, (and sorry for the double post) I should say that programmers in general seem to like dense lines of code - not just C coders. The good ones will at least try to make them readable. This is not a slam, but ties in nicely with Malcolm’s assertion that “Programmers are Lazy”.

rob

By: boolean

boolean — Fri, 11 Feb 2005 13:06:19 +0000

Part of the problem is the tendency for C programmers to embed as much on a line as possible. Especially for failure conditions. Something I’ve forced myself to do over the past couple of years is include a separate test and exit for all failure conditions. I do this partly because of the ugliness of nesting conditionals in Smalltalk, but I’ve also found that it has a side-effect of more detailed failures.

ok, make fun of the smalltalker now.

ps, hi zab!

By: Peter

Peter — Thu, 10 Feb 2005 21:08:08 +0000

I just had the exact same problem, exact same context -trying to install cricket. Thank you for saving me some of the frustration you went through.

-peter

By: Malcolm

Malcolm — Mon, 31 Jan 2005 22:36:54 +0000

Certainly true. As someone who gets called when this sort of thing happens, it infuriates me sometimes how frequently I have to fire up a debugger or use some sort of tracer to find out what’s really going on, when I simple descriptive error message would do the trick.

I think of this as the “theory of relative locative density of work”. For any given decision about how something should break, programmers tend to see the amount of work that they will have to do, compared to the amount of work I will have to do, as being not worth their time to fix. It’s harder for them to add an extra line or two of code to print a reasonable, accurate error message than it is for me to reverse engineer what happened. I used to think that this was because programmers were Gods who thought “of course, people will just look at the source and see this obvious thing”, but now I realize that it’s because programmers, as a group, are lazy, undisciplined nitwits.