Date: Tue, 14 Jan 1997 03:04:58 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: bde@zeta.org.au (Bruce Evans) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.org Subject: Re: unused variable in su Message-ID: <Mutt.19970114030458.davidn@labs.blaze.net.au> In-Reply-To: <199701131017.VAA14907@godzilla.zeta.org.au>; from Bruce Evans on Jan 13, 1997 21:17:04 %2B1100 References: <199701131017.VAA14907@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes: > >> Still, it's fairly obfuscated code. It could be better worded: > > > >IMHO, it is fine (and yes, it should be strncpy()). Using the return > > It should be strdup(). Using strncpy() or snprintf() to handle buffer > overflows by truncating the string is sloppy. No, it is defensive programming, pure and simple. The buffer already IS a reasonable size - in fact, it is the maximum legal path size. If the string copied into it is too long, then it is going to get rejected by the execvp() anyway - only the error number changes - EEXIST vs. ENAMETOOLONG. Toss a coin, either approach is reasonable. There is an advantage the snprintf() case, at least you can detect if the formatted string would have overflowed. Although it seems that the snprintf() return value is not often (enough) checked. IMHO, it should be, perhaps even via syslog(), if early notification of possible attacks is useful. I would agree that using arbitrarily undersized buffers is sloppy, but that is not the case here. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970114030458.davidn>