Date: Fri, 25 May 2001 06:00:02 -0700 (PDT) From: Peter Pentchev <roam@orbitel.bg> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/27636: inetd's internal "auth" service exploits possible bug Message-ID: <200105251300.f4PD02215923@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/27636; it has been noted by GNATS. From: Peter Pentchev <roam@orbitel.bg> To: Jeremy Chadwick <jdc@parodius.com> Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/27636: inetd's internal "auth" service exploits possible bug Date: Fri, 25 May 2001 15:49:51 +0300 On Fri, May 25, 2001 at 05:33:49AM -0700, Jeremy Chadwick wrote: > > >Number: 27636 > >Category: bin > >Synopsis: inetd's internal "auth" service exploits possible bug > >Originator: Jeremy Chadwick > >Organization: > Parodius Networking > >Environment: > System: FreeBSD pentarou.parodius.com 4.3-STABLE FreeBSD 4.3-STABLE #0: Sat May 19 19:55:39 PDT 2001 root@pentarou.parodius.com:/usr/obj/usr/src/sys/PARODIUS-SMP i386 > > > >Description: > [snip] > sysctlbyname(), in this case, returns -1 and sets errno to > ENOENT. sysctlbyname() is being called against a "mysterious" > sysctl variable, "net.inet.tcp.getcred." I use the word "mysterious" > because the entry is 1. undocumented, 2. returns ENOENT, and 3. > ENOENT is not listed in the sysctlbyname(3) manpage as a valid > error code (but the kernel **DOES** return ENOENT!). > > Could someone please 1. fix this issue, 2. explain why ENOENT > was chosen as a return value for the kernel (when it doesn't > seem to be interacting with any files in this case), and 3. fix > the manpage so that it contains proper updated information? Just as a random thought: I'd guess that the inappropriate wording is not in choosing ENOENT, but in the (all too common) representation of this error as 'no such file or directory'. From the name, it would seem that ENOENT was meant as a generic 'no such entity' return code to be used for all types of objects, not just files or directories. The error message was crafted that way because in the overwhelming majority of cases, an ENOENT error refers to a file-type object. In this particular case, I believe ENOENT is the appropriate error code for a non-existing sysctl name (and why not for MIB's, too?), and IMHO, the documentation (and kernel sysctl code) should be changed to refer to ENOENT, and not the currently used EOPNOTSUPP, for both names and MIB's. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105251300.f4PD02215923>