Re: small c problem
- To: Debian Mentors list <debian-mentors@lists.debian.org>
- Subject: Re: small c problem
- From: Jeff Licquia <jeff@luci.org>
- Date: Wed, 7 Jul 1999 22:42:52 -0500
- Message-id: <[🔎] 19990707224252.B13894@server1.jtja-l.com>
- In-reply-to: <19990630203051.K16440@darren.benham.net>; from Darren O. Benham on Wed, Jun 30, 1999 at 08:30:51PM -0700
- References: <Pine.LNX.4.05.9907011510270.2958-100000@omnic.dhis.org> <19990630203051.K16440@darren.benham.net>
On Wed, Jun 30, 1999 at 08:30:51PM -0700, Darren O. Benham wrote:
>
> No, well, yes.. well.. for starters, you need a buffer, not a pointer.
> rad_cmd has no space to hold "number:444". Change it to
> char rad_cmd[x] where x is some number that will hold the maximum size of
> the string + 1.
>
> Then you can do...
>
> sprintf( rad_cmd, "number:%u", freq_num );
Please accomodate this paranoid, if you would...
snprintf() is better than sprintf(), both for reliability and for
security reasons. snprintf() takes a length parameter, and will not
fill the buffer past its end. Using sprintf() (and strcat() for that
matter, and all manner of other string functions) in setuid and
root-owned processes is the #1 cause of security problems under both
Unix and NT.
Yes, this use of sprintf() is likely OK, since you control the one
variable used. And perhaps this won't be root-owned or setuid in
normal circumstances. Still, it's a good habit to get into.
No offense intended or implied of anyone. Please don't get ruffled;
I'd rather be a bit paranoid than see Debian's name front and center
on bugtraq any more than it has to.
Reply to: