On Wed, Aug 27, 2008 at 5:18 AM, Stephen R. van den Berg <srb@xxxxxxx> wrote: > Avery Pennarun wrote: >>In general I'd mostly agree with you, but fd 0/1/2 are super-special >>and I've personally been bitten by insane, rare problems that occur >>when programs are started with one or more of those fds closed. > > Key words: "insane, rare problems" Yes, I used those words on purpose. > Well, as you say, "you're writing a new daemon". This means that you > need to make sure that *if* this daemon ever forks/execs it leaves the > environment in a sane state which does not open up security holes. Well, *I* know that. But this is far from well-documented. >>Does this sound rare? It is! But it's also hellish to debug when it >>happens, precisely because of its rarity. For example, in one case, I >>had this problem because an sfdisk process started by my custom > > Thing is, by making git (and some other programs) hide this problem > from you, this problem will get even *harder* to debug. Whereas as a > daemon author you should be thankful that something breaks and shows you > your daemon needs fixing. True enough, unless it was worked around in libc or the kernel as I suggested. That said, if git opens a file and writes random log messages to it, I'd still consider that to be git's fault for doing so. I'm just feeling protective of the future sanity of other developers here, hoping they don't have to go through what I did on a multi-week bug hunt. (We were even blaming reiserfs for a while for our boot sector getting zapped...) The fact that someone *other* than me has suggested this change implies that I'm not the only one who has seen such insanity in the wild. It'd be fine if git simply died if fd 0, 1, or 2 isn't open when it starts. Printing a warning message wouldn't work, for hopefully obvious reasons. But it would be a shame to simply ignore this sort of problem now that it's been brought up. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
