Bug 27636

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.

On Fri, May 25, 2001 at 03:49:51PM +0300, roam@orbitel.bg wrote:
> 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.

	True; I'm hearing you on FM.  However, there's a whole slew
	of available error codes for reporting something much more
	proper, in errno.h.  Something gives me the impression (and I
	could be flat-out wrong with this assumption) that the author
	of the kernel code chose ENOENT because it was quick-and-dirty.
	As I don't have any idea what the kernel code actually *does*, I
	suppose I'm out on a limb.

> 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.

	There's multiple issues to this bug report, as you can tell.
	Half of them relate to inetd, the other half relate to the
	sysctlbyname() issue and it's (lack-of) documentation.  I
	wasn't sure if send-pr permitted multiple categories, other-
	wise I would have picked "bin,kern."

	Here's the best part: the sysctl variable *DOES* indeed exist.
	Herein lies the magic:

[5:53/pentarou] ~$ su2
Password:
[5:53/pentarou] /home/jdc$ sysctl net.inet.tcp.foobar
sysctl: unknown oid 'net.inet.tcp.foobar'
[5:53/pentarou] /home/jdc$ sysctl net.inet.tcp.getcred
[5:53/pentarou] /home/jdc$ sysctl net.inet.udp.getcred
[5:53/pentarou] /home/jdc$ 

	I find this very peculiar.  I am lead to believe that basically
	the results of a sysctlbyname(3) call on the entry for
	net.inet.[tcp|udp].getcred are supposed to contain the UID of
	the owner of the socket.  I'm not quite sure *WHY* sysctl was
	chosen for this, but I digress...

	It's possible that inetd is not properly passing the correct
	socket structures to sysctlbyname(), or that they're not
	being filled correctly prior to the call itself.  I'm lead
	to believe this solely because of the kernel code I looked
	at.  It's also possible that error code 2 is the return code
	for "No credentials for that socket."  I really don't know, as
	the entire sysctl variable itself seems special.  I'm totally
	unsure either way; I just know pidentd does the same call and
	does not have this problem.

	I believe inetd should be returning "NO-USER" in this case.

	"No such file or directory" is *very* misleading, as I'm sure
	all of us will agree; the error implies a worse problem, and
	could cause system administrators to go on a wild goose chase
	searching for nothing.  Not to mention, who knows what outsiders
	think ("No such file or directory? Niiice...").

	Just food for thought.  *crossing fingers on a fix*  :-)

-- 
| Jeremy Chadwick                                     jdc@parodius.com |
| Parodius Networking                         http://www.parodius.com/ |
| UNIX Systems Administrator                    Mountain View, CA, USA |

Comment 3 dwmalone 2001-05-25 14:38:30 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

I'll have a look at this. The real problem seems to be that the builtin 
ident service can return strings not permitted by the RFC.

Comment 4 dwmalone 2001-07-17 11:45:58 UTC

State Changed
From-To: open->closed

Issue addressed in -current and -stable.