Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Apr 2002 10:40:44 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Garrett Wollman <wollman@lcs.mit.edu>
Cc:        "M. Warner Losh" <imp@village.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_descrip.c kern_exec.c src/sys/sys filedesc.h
Message-ID:  <Pine.NEB.3.96L.1020419103914.64976x-100000@fledge.watson.org>
In-Reply-To: <200204190420.g3J4KMC69617@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 19 Apr 2002, Garrett Wollman wrote:

> <<On Thu, 18 Apr 2002 22:01:25 -0600 (MDT), "M. Warner Losh" <imp@village.org> said:
> 
> > There is no other way to fix this than in the kernel...
> 
> Sure there is -- make sure that every privileged process has something
> on every fd.  You could do it in csu (although from a standards
> perspective that would make no difference).  Or, alternatively, rather
> than changing exec(), you could change fdalloc() to never return fd 0,
> 1, or 2 except when explicitly requested by dup2() -- although this
> would break some seriously old programs that expect to be able to do
> 
> 	fd = open(...)
> 	close(1);
> 	dup(fd);
> 
> and have it work.  (These programs are broken anyway -- the Standard
> does not guarantee any particular order of fd allocation.) 

The policy decision regarding whether a program is "privileged" still has
to be made in the kernel, regardless of whether the fd problem is
addressed in kernel or user space.  We discussed the "don't return 0 1 and
2" fd's, but apparently many programs specifically rely on 0 1 and 2 being
returned sequentially, and that is written into some spec or another.  I
think this solution is a reasonable one -- many of the other "easy"
solutions more explicitly violate the specs than this one, as far as I can
tell.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020419103914.64976x-100000>