From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 22:41:29 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607BB16A46E for ; Mon, 12 Nov 2007 22:41:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 20FED13C4B9 for ; Mon, 12 Nov 2007 22:41:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7D7074765F; Mon, 12 Nov 2007 17:42:48 -0500 (EST) Date: Mon, 12 Nov 2007 22:41:17 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yuri In-Reply-To: <1194906161.4738d231c0fe4@webmail.rawbw.com> Message-ID: <20071112223212.V81124@fledge.watson.org> References: <1194896018.4738aa922f776@webmail.rawbw.com> <20071112214243.Y81124@fledge.watson.org> <1194906161.4738d231c0fe4@webmail.rawbw.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org Subject: Re: How to get filename of an open file descriptor X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 22:41:29 -0000 On Mon, 12 Nov 2007, Yuri wrote: > I looked at the patch. It retrieves file description information through > 'sysctl' calls with proprietary keys. > > Isn't it better architecturally to expose the same information through > procfs interface? At least from the filesystem level and up standard tools > like ls/cat will be able to show the the same information instead of the > specialized utility. Over the last several years, we have been working to deprecate procfs as a means as the official means of querying information. This has been for several reasons: (1) procfs has been a major source of security vulnerabilities in every operating system that implements it. You need only look at the vulnerability history of Solaris, Linux, and earlier versions of FreeBSD to see the rather copious list of problems. My belief is that this derives from the fundamental misalignment of the concepts of processes and files: their life cycles are very different, and there appear to be particular problems relating to execve(), which may reflect a security transition that has no logical equivilent revocation point for files. Most of the vulnerabilities have to do with a failure to properly revoke across execution of setuid binaries, and these vulnerabilities seem remarkable persistent over time. (2) procfs is an unstructured query mechanism--sysctl defines certain atomicity properties, has a structured get/set model, and standardized tools for querying simple data. There are well-defined interfaces for requesting the size of the data, etc. Especially for objects that are dynamic in nature, properly implementing buffering of potentially stateful non-atomic queries in a synthetic file system is quite a mess. (3) For non-human interpretation of data, such as monitoring programs, visualization programs, debugging programs, etc, we can avoid marshaling to text and then demarshaling all data on its way through the query interface, which is a common source of bugs (especially when it comes to parsing data that may be defined by untrusted processes, or even just signed vs. unsigned data). I agree there are real trade-offs being made here that can reasonably be debated, but procstat(1) is pretty consistent with our overall direction, and the reasons for the direction are relatively sound. Robert N M Watson Computer Laboratory University of Cambridge