linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Re: kernel bug in socketpair()
@ 2003-07-23 14:28 David Korn
  2003-07-23 14:46 ` David S. Miller
  0 siblings, 1 reply; 20+ messages in thread
From: David Korn @ 2003-07-23 14:28 UTC (permalink / raw)
  To: davem; +Cc: gsf, linux-kernel, netdev


> 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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 14:28 Re: kernel bug in socketpair() David Korn
@ 2003-07-23 14:46 ` David S. Miller
  2003-07-23 16:56   ` Glenn Fowler
  0 siblings, 1 reply; 20+ messages in thread
From: David S. Miller @ 2003-07-23 14:46 UTC (permalink / raw)
  To: David Korn; +Cc: gsf, linux-kernel, netdev

On Wed, 23 Jul 2003 10:28:22 -0400 (EDT)
David Korn <dgk@research.att.com> wrote:

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

Someone else would have to comment, but I do know we've had
this behavior since day one.

And therefore I wouldn't be doing many people much of a favor
by changing the behavior today, what will people do who need
their things to work on the bazillion existing linux kernels
running out there? :-)

Also, see below for another reason why this behavior is unlikely
to change.

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

Look at the /proc file we put there for socket FD's.  It's a symbolic
link with a readable string of the form ("socket:[%d]", inode_nr)

So your program ends up doing a follow of a symbolic link with that
string name, which does not exist.

Thinking more about this, changing this behavior would probably break
more programs than it would help begin to function, so this is unlikely
to ever change.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 14:46 ` David S. Miller
@ 2003-07-23 16:56   ` Glenn Fowler
  2003-07-23 17:00     ` David S. Miller
  2003-07-23 17:50     ` Alan Cox
  0 siblings, 2 replies; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 16:56 UTC (permalink / raw)
  To: davem, dgk; +Cc: linux-kernel, netdev


you can eliminate the security implications for all fd types by
simply translating
	open("/dev/fd/N",...)
to
	dup(atoi(N))
w.r.t. fd N in the current process

the problem is that linux took an implementation shortcut by symlinking
	/dev/fd/N -> /proc/self/fd/N
and by the time the kernel sees /proc/self/fd/N the "self"-ness is apparently
lost, and it is forced to do the security checks

if the /proc fd open code has access to the original /proc/PID/fd/N path
then it can do dup(atoi(N)) when the PID is the current process without
affecting security

otherwise there is a bug in the /dev/fd/N -> /proc/self/fd/N implementation
and /dev/fd/N should be separated out to its (original) dup(atoi(N))
semantics

see http://mail-index.netbsd.org/current-users/1994/03/29/0027.html for
an early (bsd) discussion of /dev/fd/N vs. /proc/self/fd/N

-- Glenn Fowler <gsf@research.att.com> AT&T Labs Research, Florham Park NJ --

On Wed, 23 Jul 2003 07:46:15 -0700 David S. Miller wrote:
> On Wed, 23 Jul 2003 10:28:22 -0400 (EDT)
> David Korn <dgk@research.att.com> wrote:

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

> Someone else would have to comment, but I do know we've had
> this behavior since day one.

> And therefore I wouldn't be doing many people much of a favor
> by changing the behavior today, what will people do who need
> their things to work on the bazillion existing linux kernels
> running out there? :-)

> Also, see below for another reason why this behavior is unlikely
> to change.

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

> Look at the /proc file we put there for socket FD's.  It's a symbolic
> link with a readable string of the form ("socket:[%d]", inode_nr)

> So your program ends up doing a follow of a symbolic link with that
> string name, which does not exist.

> Thinking more about this, changing this behavior would probably break
> more programs than it would help begin to function, so this is unlikely
> to ever change.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 16:56   ` Glenn Fowler
@ 2003-07-23 17:00     ` David S. Miller
  2003-07-23 17:24       ` Glenn Fowler
  2003-07-23 19:41       ` Andreas Jellinghaus
  2003-07-23 17:50     ` Alan Cox
  1 sibling, 2 replies; 20+ messages in thread
From: David S. Miller @ 2003-07-23 17:00 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 12:56:12 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> the problem is that linux took an implementation shortcut by symlinking
> 	/dev/fd/N -> /proc/self/fd/N
> and by the time the kernel sees /proc/self/fd/N the "self"-ness is apparently
> lost, and it is forced to do the security checks

None of this is true.  If you open /proc/self/fd/N directly the problem
is still there.

> if the /proc fd open code has access to the original /proc/PID/fd/N path
> then it can do dup(atoi(N)) when the PID is the current process without
> affecting security

If we're talking about the current process, there is no use in using
/proc/*/fd/N to open a file descriptor in the first place, you can
simply call open(N,...)

I've personally always viewed /proc/*/fd/N as a way to see who has
various files or sockets open, ie. a debugging tool, not as a generic
way for processes to get access to each other's FDs.

There is an existing mechanism, a portable non-Linux one, that you
can use to do that.

Pass the fd over a UNIX domain socket if you want that, truly.
That works on every system.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 17:00     ` David S. Miller
@ 2003-07-23 17:24       ` Glenn Fowler
  2003-07-23 17:31         ` David S. Miller
  2003-07-23 19:41       ` Andreas Jellinghaus
  1 sibling, 1 reply; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 17:24 UTC (permalink / raw)
  To: davem, gsf; +Cc: dgk, linux-kernel, netdev


On Wed, 23 Jul 2003 10:00:43 -0700 David S. Miller wrote:
> On Wed, 23 Jul 2003 12:56:12 -0400 (EDT)
> Glenn Fowler <gsf@research.att.com> wrote:

> > the problem is that linux took an implementation shortcut by symlinking
> > 	/dev/fd/N -> /proc/self/fd/N
> > and by the time the kernel sees /proc/self/fd/N the "self"-ness is apparently
> > lost, and it is forced to do the security checks

> None of this is true.  If you open /proc/self/fd/N directly the problem
> is still there.

you missed the point that the original open() call is on /dev/fd/N,
not /proc/PID/fd/N; /proc/PID/fd/N only comes into play because the
linux implementation foists it on the user

> > if the /proc fd open code has access to the original /proc/PID/fd/N path
> > then it can do dup(atoi(N)) when the PID is the current process without
> > affecting security

> If we're talking about the current process, there is no use in using
> /proc/*/fd/N to open a file descriptor in the first place, you can
> simply call open(N,...)

no, in the notation above N is the fd number "so you could simply call dup(N)"

here is one reason why /dev/fd/N is useful:

/dev/fd/N is the underlying mechanism for implementing the bash and ksh

	cmd-1 <(cmd-2 ...) ... <(cmd-n ...)

each <(cmd-i ...) is converted to a pipe() with the write side getting the
output of cmd-i (and marked close on exec) and the read side *not* marked
close on exec; cmd-1 is then executed as

	cmd-1 /dev/fd/PIPE-READ-2 ... /dev/fd/PIPE-READ-n

where PIPE-READ-i is the fd number of the read side of the pipe for cmd-i


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 17:24       ` Glenn Fowler
@ 2003-07-23 17:31         ` David S. Miller
  2003-07-23 18:14           ` Glenn Fowler
  0 siblings, 1 reply; 20+ messages in thread
From: David S. Miller @ 2003-07-23 17:31 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: gsf, dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 13:24:36 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> /dev/fd/N is the underlying mechanism for implementing the bash and ksh
> 
> 	cmd-1 <(cmd-2 ...) ... <(cmd-n ...)
> 

Interesting.

I looked at the bash code, and it uses pipes with /dev/fd/N, and for
/dev/fd/N which are pipes the open should work under Linux.

This is what David Korn said in his original report.

I guess the part that is left is the fchmod() issue which exists
because one inode is used to implement both sides of the pipe under
Linux.

Was the idea to, since fchmod() on pipes modified both sides,
to use UNIX domain sockets to implement this?  And that's how
you discovered the /dev/fd/N failure for sockets?

Another idea is to use named unix sockets.  Can that be
sufficient to solve your dilemma?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 16:56   ` Glenn Fowler
  2003-07-23 17:00     ` David S. Miller
@ 2003-07-23 17:50     ` Alan Cox
  2003-07-23 23:27       ` Bill Rugolsky Jr.
  1 sibling, 1 reply; 20+ messages in thread
From: Alan Cox @ 2003-07-23 17:50 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: davem, dgk, Linux Kernel Mailing List, netdev

On Mer, 2003-07-23 at 17:56, Glenn Fowler wrote:
> you can eliminate the security implications for all fd types by
> simply translating
> 	open("/dev/fd/N",...)
> to
> 	dup(atoi(N))
> w.r.t. fd N in the current process

This has very different semantics. Consider lseek().

> otherwise there is a bug in the /dev/fd/N -> /proc/self/fd/N implementation
> and /dev/fd/N should be separated out to its (original) dup(atoi(N))
> semantics

I don't see a bug. I see differing behaviour between Linux and BSD on a
completely non standards defined item. Also btw nobody ever really wrote
a /dev/fd/ for Linux - it was just a byproduct of the proc stuff someone
noticed. I guess someone could write a Plan-9 style dev/fd or devfdfs
for Linux if they wanted.

Alan


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 17:31         ` David S. Miller
@ 2003-07-23 18:14           ` Glenn Fowler
  2003-07-23 18:23             ` David S. Miller
  0 siblings, 1 reply; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 18:14 UTC (permalink / raw)
  To: davem, gsf; +Cc: dgk, linux-kernel, netdev


On Wed, 23 Jul 2003 10:31:35 -0700 David S. Miller wrote:
> Interesting.

> I looked at the bash code, and it uses pipes with /dev/fd/N, and for
> /dev/fd/N which are pipes the open should work under Linux.

> This is what David Korn said in his original report.

> I guess the part that is left is the fchmod() issue which exists
> because one inode is used to implement both sides of the pipe under
> Linux.

> Was the idea to, since fchmod() on pipes modified both sides,
> to use UNIX domain sockets to implement this?  And that's how
> you discovered the /dev/fd/N failure for sockets?

fchmod() came into play with socketpair() to get the fd modes to match
pipe(); its not needed with pipe()

we use socketpair() to allow efficient peeking on pipe input (via recv()),
where peek means "read some data but don't advance the read/seek offset"
btw, this is on systems that don't allow ioctl(I_PEEK) on pipe() fds;
if there is a way to peek pipe() data on linux then we can switch back
to pipe() and be on our way

> Another idea is to use named unix sockets.  Can that be
> sufficient to solve your dilemma?

named sockets seem a little heavyweight for this application


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 18:14           ` Glenn Fowler
@ 2003-07-23 18:23             ` David S. Miller
  2003-07-23 18:54               ` Glenn Fowler
  0 siblings, 1 reply; 20+ messages in thread
From: David S. Miller @ 2003-07-23 18:23 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: gsf, dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 14:14:57 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> named sockets seem a little heavyweight for this application

I think it'll be cheaper than unnamed unix sockets and
groveling in /proc/*/fd/

And even if there is a minor performance issue, you'll more than get
that back due to the portability gain. :-)

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 18:23             ` David S. Miller
@ 2003-07-23 18:54               ` Glenn Fowler
  2003-07-23 19:04                 ` David S. Miller
  2003-07-23 19:08                 ` Alan Cox
  0 siblings, 2 replies; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 18:54 UTC (permalink / raw)
  To: davem, gsf; +Cc: dgk, linux-kernel, netdev


On Wed, 23 Jul 2003 11:23:07 -0700 David S. Miller wrote:
> On Wed, 23 Jul 2003 14:14:57 -0400 (EDT)
> Glenn Fowler <gsf@research.att.com> wrote:

> > named sockets seem a little heavyweight for this application

> I think it'll be cheaper than unnamed unix sockets and
> groveling in /proc/*/fd/

> And even if there is a minor performance issue, you'll more than get
> that back due to the portability gain. :-)

named unix sockets reside in the fs namespace, no?
so they must be linked to a dir before use and unlinked after use
the unlink after use would be particularly tricky for the parent process
implementing
	cmd <(cmd ...) ...


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 18:54               ` Glenn Fowler
@ 2003-07-23 19:04                 ` David S. Miller
  2003-07-23 19:11                   ` Glenn Fowler
  2003-07-23 19:08                 ` Alan Cox
  1 sibling, 1 reply; 20+ messages in thread
From: David S. Miller @ 2003-07-23 19:04 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: gsf, dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 14:54:49 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> On Wed, 23 Jul 2003 11:23:07 -0700 David S. Miller wrote:
> > On Wed, 23 Jul 2003 14:14:57 -0400 (EDT)
> > Glenn Fowler <gsf@research.att.com> wrote:
> 
> > > named sockets seem a little heavyweight for this application
> 
> > I think it'll be cheaper than unnamed unix sockets and
> > groveling in /proc/*/fd/
> 
> > And even if there is a minor performance issue, you'll more than get
> > that back due to the portability gain. :-)
> 
> named unix sockets reside in the fs namespace, no?

Right.

> so they must be linked to a dir before use and unlinked after use
> the unlink after use would be particularly tricky for the parent process
> implementing
> 	cmd <(cmd ...) ...

Hmmm... true.

I honestly don't know what to suggest you use, sorry :(

Is bash totally broken because of all this?  Or does the problem only
trigger when using (cmd) subprocesses in a certain way?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 18:54               ` Glenn Fowler
  2003-07-23 19:04                 ` David S. Miller
@ 2003-07-23 19:08                 ` Alan Cox
  1 sibling, 0 replies; 20+ messages in thread
From: Alan Cox @ 2003-07-23 19:08 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: davem, dgk, Linux Kernel Mailing List, netdev

On Mer, 2003-07-23 at 19:54, Glenn Fowler wrote:
> named unix sockets reside in the fs namespace, no?
> so they must be linked to a dir before use and unlinked after use
> the unlink after use would be particularly tricky for the parent process
> implementing
> 	cmd <(cmd ...) ...

Portable stuff yes, Linux also supports a pure socket namespace for them
when the path starts with a nul character


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 19:04                 ` David S. Miller
@ 2003-07-23 19:11                   ` Glenn Fowler
  2003-07-23 19:14                     ` David S. Miller
  0 siblings, 1 reply; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 19:11 UTC (permalink / raw)
  To: davem, gsf; +Cc: dgk, linux-kernel, netdev


On Wed, 23 Jul 2003 12:04:57 -0700 David S. Miller wrote:
> Is bash totally broken because of all this?  Or does the problem only
> trigger when using (cmd) subprocesses in a certain way?

bash uses pipe() so its ok
using socketpair() instead of pipe() introduces the problem
and we will now have to find an alternative to work around the
linux /dev/fd/N implementation

thanks


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 19:11                   ` Glenn Fowler
@ 2003-07-23 19:14                     ` David S. Miller
  2003-07-23 19:29                       ` Glenn Fowler
  0 siblings, 1 reply; 20+ messages in thread
From: David S. Miller @ 2003-07-23 19:14 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: gsf, dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 15:11:47 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> On Wed, 23 Jul 2003 12:04:57 -0700 David S. Miller wrote:
> > Is bash totally broken because of all this?  Or does the problem only
> > trigger when using (cmd) subprocesses in a certain way?
> 
> bash uses pipe() so its ok
> using socketpair() instead of pipe() introduces the problem
> and we will now have to find an alternative to work around the
> linux /dev/fd/N implementation

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?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 19:14                     ` David S. Miller
@ 2003-07-23 19:29                       ` Glenn Fowler
  2003-07-23 19:56                         ` David S. Miller
  2003-07-23 22:24                         ` jw schultz
  0 siblings, 2 replies; 20+ messages in thread
From: Glenn Fowler @ 2003-07-23 19:29 UTC (permalink / raw)
  To: davem, gsf; +Cc: dgk, linux-kernel, netdev


On Wed, 23 Jul 2003 12:14:36 -0700 David S. Miller wrote:
> I missed the reason why you can't use pipes and bash
> is able to, what is it?

we have some applications, ksh included, with semantics that require
stdin be read at most one line at a time; an inefficient implementation
of this does 1 byte read()s until newline is read; an efficient
implementation does a peek read (without advancing the read/seek offset),
determines how many chars to read up to and including the newline,
and then read()s that much

linux has ioctl(I_PEEK) for stream devices and recv() for sockets,
and neither of these work on pipes; if there is a linux alternative
for pipes then we'd be glad to use it

we switched from pipe() to socketpair() to take advantage of the linux
recv() peek read


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 17:00     ` David S. Miller
  2003-07-23 17:24       ` Glenn Fowler
@ 2003-07-23 19:41       ` Andreas Jellinghaus
  1 sibling, 0 replies; 20+ messages in thread
From: Andreas Jellinghaus @ 2003-07-23 19:41 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-kernel

On Mit, 2003-07-23 at 19:00, David S. Miller wrote:
> If we're talking about the current process, there is no use in using
> /proc/*/fd/N to open a file descriptor in the first place, you can
> simply call open(N,...)

maybe you can use open on /proc/fd/*/N to open a file
already deleted from the filesystem? That might be useful.

Andreas


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 19:29                       ` Glenn Fowler
@ 2003-07-23 19:56                         ` David S. Miller
  2003-07-23 22:24                         ` jw schultz
  1 sibling, 0 replies; 20+ messages in thread
From: David S. Miller @ 2003-07-23 19:56 UTC (permalink / raw)
  To: Glenn Fowler; +Cc: gsf, dgk, linux-kernel, netdev

On Wed, 23 Jul 2003 15:29:03 -0400 (EDT)
Glenn Fowler <gsf@research.att.com> wrote:

> linux has ioctl(I_PEEK) for stream devices and recv() for sockets,
> and neither of these work on pipes; if there is a linux alternative
> for pipes then we'd be glad to use it

Alan mentioned the pure-socket namespace we have for named unix
sockets, but I don't think you can actually use it for your
problem unfortunately.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 19:29                       ` Glenn Fowler
  2003-07-23 19:56                         ` David S. Miller
@ 2003-07-23 22:24                         ` jw schultz
  1 sibling, 0 replies; 20+ messages in thread
From: jw schultz @ 2003-07-23 22:24 UTC (permalink / raw)
  To: linux-kernel

On Wed, Jul 23, 2003 at 03:29:03PM -0400, Glenn Fowler wrote:
> 
> On Wed, 23 Jul 2003 12:14:36 -0700 David S. Miller wrote:
> > I missed the reason why you can't use pipes and bash
> > is able to, what is it?
> 
> we have some applications, ksh included, with semantics that require
> stdin be read at most one line at a time; an inefficient implementation
> of this does 1 byte read()s until newline is read; an efficient
> implementation does a peek read (without advancing the read/seek offset),
> determines how many chars to read up to and including the newline,
> and then read()s that much
> 
> linux has ioctl(I_PEEK) for stream devices and recv() for sockets,
> and neither of these work on pipes; if there is a linux alternative
> for pipes then we'd be glad to use it
> 
> we switched from pipe() to socketpair() to take advantage of the linux
> recv() peek read

Perhaps you'd rather code a patch adding peek functionality
for pipes.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: kernel bug in socketpair()
  2003-07-23 17:50     ` Alan Cox
@ 2003-07-23 23:27       ` Bill Rugolsky Jr.
  0 siblings, 0 replies; 20+ messages in thread
From: Bill Rugolsky Jr. @ 2003-07-23 23:27 UTC (permalink / raw)
  To: Alan Cox; +Cc: Glenn Fowler, davem, dgk, Linux Kernel Mailing List, netdev

On Wed, Jul 23, 2003 at 06:50:41PM +0100, Alan Cox wrote:
> > otherwise there is a bug in the /dev/fd/N -> /proc/self/fd/N implementation
> > and /dev/fd/N should be separated out to its (original) dup(atoi(N))
> > semantics
>
> I don't see a bug. I see differing behaviour between Linux and BSD on a
> completely non standards defined item. Also btw nobody ever really wrote
> a /dev/fd/ for Linux - it was just a byproduct of the proc stuff someone
> noticed. I guess someone could write a Plan-9 style dev/fd or devfdfs
> for Linux if they wanted.

I first posted about this several years ago, and it came up again earlier
in the year; see:

http://hypermail.idiosynkrasia.net/linux-kernel/archived/2003/week14/0314.html

As HPA and I had previously discussed, ->open() methods always return
a new file struct, so providing the dup() semantics would require a
restructuring of the ->open() methods -- unless, (and this is a dirty
hack,) one creates a devfdfs that abuses the ERESTART_RESTARTBLOCK
mechanism to restart the open() syscall with dup() instead.  This requires
some minor pollution to the open() syscall path to interpret the error
return, but should require no other changes.

Regards,

        Bill Rugolsky


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Re: kernel bug in socketpair()
@ 2003-07-23 19:28 David Korn
  0 siblings, 0 replies; 20+ messages in thread
From: David Korn @ 2003-07-23 19:28 UTC (permalink / raw)
  To: davem, dgk, gsf, linux-kernel, netdev

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2003-07-23 23:12 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-23 14:28 Re: kernel bug in socketpair() David Korn
2003-07-23 14:46 ` David S. Miller
2003-07-23 16:56   ` Glenn Fowler
2003-07-23 17:00     ` David S. Miller
2003-07-23 17:24       ` Glenn Fowler
2003-07-23 17:31         ` David S. Miller
2003-07-23 18:14           ` Glenn Fowler
2003-07-23 18:23             ` David S. Miller
2003-07-23 18:54               ` Glenn Fowler
2003-07-23 19:04                 ` David S. Miller
2003-07-23 19:11                   ` Glenn Fowler
2003-07-23 19:14                     ` David S. Miller
2003-07-23 19:29                       ` Glenn Fowler
2003-07-23 19:56                         ` David S. Miller
2003-07-23 22:24                         ` jw schultz
2003-07-23 19:08                 ` Alan Cox
2003-07-23 19:41       ` Andreas Jellinghaus
2003-07-23 17:50     ` Alan Cox
2003-07-23 23:27       ` Bill Rugolsky Jr.
2003-07-23 19:28 David Korn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).