Date: Wed, 15 Nov 1995 10:24:26 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Bruce Evans <bde@zeta.org.au> Cc: peter@jhome.dialix.com, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, phk@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <2593.816427466@critter.tfs.com> In-Reply-To: Your message of "Wed, 15 Nov 1995 15:29:43 %2B1100." <199511150429.PAA17458@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I noticed a whole class of (old) sysctl bugs. Consider e.g., > setdomainname(). The string is copied in directly over the > old string. If the copyin() faults, the old string is trashed. > sysctl() returns EFAULT but the caller has no way of knowing > if the old value is trashed. > > To avoid this, all copyin()s should go to temporary storage. > The bad malloc() method worked better here :-). Hmm, yeah, but how to tell when to use it. I could complicate the policy a bit: copyout(->old) if (error) return (error) copyin(<-new) if (error && we_did_copyout) copyin(<-old) return (error); But is it really worth it ? > >The interface is badly designed, how about this one: > > > get some variable > > old buffer too small, > > new buffer correct. > > >it should return ENOMEM because it cannot copyout, but should the > >new value be installed ? > > mpp and I fixed sysctl_string() to copyout as much as fits. > 4.4lite2 is still broken here (it returns immediately). We decided > to install the new value in the ENOMEM case. This is probably > wrong. I think so... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2593.816427466>