Path: utzoo!attcan!uunet!munnari.oz.au!metro!cluster!necisa!boyd From: boyd@necisa.ho.necisa.oz (Boyd Roberts) Newsgroups: comp.unix.internals Subject: Re: Trojan Horses Message-ID: <1885@necisa.ho.necisa.oz> Date: 23 Oct 90 05:14:44 GMT References: <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> Organization: NEC Information Systems Australia Pty. Ltd. Lines: 51 In article <19547:Oct1818:25:2690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >This is a failure of NFS, not a reason to check close(). (Well, close() >should be restarted on EINTR, but that's a side issue.) It's not right >to give the programmer the burden of working around NFS's bugs. Same for >AFS. > Always, always, always check the return values of system calls. It costs nothing and can save you from potential embarassment at some laster time. It something has an error return you _must_ check for it. It's not a matter of `working around ... bugs'. It's all about good programming style. It's incredibly useful to have good diagnostics for even the worst end case. Take NFS for example. When it breaks I'd like to know which system call failed and why. That way you _know_ what's going on, or at least you have a handle on it. There's nothing worse than silence when something goes weird on you. One horror story springs to mind with setuid(2) and setgid(2). This (large) piece of code started off running as root and then went setgid() followed by setuid() to become right `user'. Did it check what setuid() and setgid() returned? How many of you check what those two return? Anyone? Anyway, the setuid() and setgid() both FAILED which caused the software to fail in strange ways. On a `real' UNIX machine this wouldn't be a problem. But, welcome to SCO and their C2 security nightmare. Because this stuff was invoked by init it had no `login user id'. The documentation for set[ug]id(2) states that both calls would fail if the `login user id' was not set. This thing can be set once and _only once_. It's done by login(1) and su(1). Goodbye UNIX semantics -- hello Mom*. Anyway, if the programmer of this piece of code (not me) had checked what set[gu]id() returned it would have been far easier to track down. At least, I would have had a pointer to the real problem rather than having to trek through a large software package with only a vague idea of what the problem was. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...'' * With apologies to Scatterbrain.