Re: Re: kernel bug in socketpair()

Re: Re: kernel bug in socketpair()

[David Korn]

cc:  gsf@research.att.com  dgk@research.att.com  linux-kernel@vger.kernel.org     netdev@oss.sgi.com
Subject: Re: Re: kernel bug in socketpair()
--------

> I missed the reason why you can't use pipes and bash
> is able to, what is it?
> 
> If it's the fchown() thing, why doesn't bash have this issue?
> 
> 

The reason is that we want to be able to peek ahead at data in
the pipe before advancing.  You can do this with recv() but
this doesn't work wtih pipes.   On some systems you can use
an ioctl() for this with pipes by Linux doesn't support this
so ksh configures to use socketpair() instead of pipe()
on Linux.  Without the ability to peek ahead on pipes, a command
like
	cat file | { head -6 > /dev/null; cat ;}
to remove the first 6 lines of a file would be hard to implement
unless head reads one byte at a time from the pipe.
(OK, you could read 6 bytes at first if you want to optimize head.)

David Korn
dgk@research.att.com

Re: Re: kernel bug in socketpair()

[David Korn]

> On Wed, 23 Jul 2003 09:32:09 -0400 (EDT)
> David Korn <dgk@research.att.com> wrote:
> 
> [ Added netdev@oss.sgi.com, the proper place to discuss networking kernel issues
> . ]
> 
> > The first problem is that files created with socketpair() are not accessible
> > via /dev/fd/n or /proc/$$/fd/n where n is the file descriptor returned
> > by socketpair().  Note that this is not a problem with pipe().
> 
> Not a bug.
> 
> Sockets are not openable via /proc files under any circumstances,
> not just the circumstances you describe.  This is a policy decision and
> prevents a whole slew of potential security holes.
> 
> 

Thanks for you quick response.

This make sense for INET sockets, but I don't understand the security
considerations for UNIX domain sockets.  Could you please elaborate?
Moreover, /dev/fd/n, (as opposed to /proc/$$/n) is restricted to
the current process and its decendents if close-on-exec is not specified.
Again, I don't understand why this would create a security problem
either since the socket is already accesible via the original
descriptor.

Finally if this is a security problem, why is the errno is set to ENXIO 
rather than EACCESS?

David Korn
dgk@research.att.com