Date: Wed, 15 Nov 1995 12:51:02 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: Bruce Evans <bde@zeta.org.au> Cc: phk@critter.tfs.com, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <Pine.BSF.3.91.951115124212.309I-100000@jhome.DIALix.COM> In-Reply-To: <199511150429.PAA17458@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Nov 1995, Bruce Evans wrote: > > 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. Remember, root doesn't make mistaks. :-) > To avoid this, all copyin()s should go to temporary storage. > The bad malloc() method worked better here :-). Hmm. Poul-Henning has used a useracc(new, newlen, B_READ) before going into the sysctl handlers. I thought this was sufficient to be reasonably sure that accidents aren't going to happen? > >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. Well.. As long as root doesn't make mistaks it's not relevant as it never happens. :-) Seriously though, It is a very definate grey area. I think you are right in both counts.. It should copyout as much as fits on ENOMEM, but if it's going to return an error, it probably should not attempt the copyin. Incidently, I think this is the new behavior of Poul-Henning's code (if copyout fails, copyin not attempted). -Peter > Bruce >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951115124212.309I-100000>