From owner-cvs-all Fri Apr 19 7:41: 7 2002 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id ACF6537B41A; Fri, 19 Apr 2002 07:40:58 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3JEeiw70324; Fri, 19 Apr 2002 10:40:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 19 Apr 2002 10:40:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garrett Wollman Cc: "M. Warner Losh" , 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 In-Reply-To: <200204190420.g3J4KMC69617@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 19 Apr 2002, Garrett Wollman wrote: > < 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