Date: Mon, 12 Nov 2007 22:41:17 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Yuri <yuri@rawbw.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: How to get filename of an open file descriptor Message-ID: <20071112223212.V81124@fledge.watson.org> In-Reply-To: <1194906161.4738d231c0fe4@webmail.rawbw.com> References: <1194896018.4738aa922f776@webmail.rawbw.com> <20071112214243.Y81124@fledge.watson.org> <1194906161.4738d231c0fe4@webmail.rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071112223212.V81124>