How to get filename of an open file descriptor

Robert Watson rwatson at FreeBSD.org
Mon Nov 12 14:41:29 PST 2007


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


More information about the freebsd-hackers mailing list