The Linux /proc Filesystem as a Programmers' Tool

> Damn, parsing proc files is just so much easier with Perl,

Originally, ifchk was a perl(1) wrapper around netstat(8) and ifconfig(8) (minus about 60% of it's current functionality).
I decided to rewrite and extend the program in C for several reasons. One was runtime performance.

Also, if I had written the Linux proc routines in perl(1), that would have required a glue layer to bind the C code to it. I don't want this added overhead, runtime or otherwise.

Also, consider systems that, as a matter of policy, do not/must not have a perl(1) interpreter installed. A firewall is a good example of this.
In my opinion, these systems should be loaded with the bare minimum to allow them to do their job. In this case, filtering packets, doing NAT, etc.
What I'm getting at here is that the addition of programmatic tools, outside of a command interpreter, on such systems, is potentially dangerous. Such additions should be justified.

The proc routines that I provide in the article can be learnt by anyone willing to invest the time to do so. Additionally, an integral aim of the piece was to also provide some background on secure file access proceedures.

> and can be used to produce real nice output.

netstat(8), with its sscanf(3) calls, is also capable of formatted output.

> http://arctic.org/~dean/scripts/bandwidth

Thanks for the URL. I'll check it out.

> it's also unclear to me why it matters if /proc/net/dev is a symlink... you're opening it read-only.

It has been my experience that /proc/net/dev has always been a zero byte file system object of type "file" (as opposed to a link/directory/fifo, etc).

The file access sequence I discuss in the article (lstat(2) -> fopen(3) -> fstat(2)) revolves around secure file access. What do I mean by that?
Well, consider this scenario. We first call stat(2) on the file, checking that it's zero bytes in size, chowned root:root, etc. If it passes these attribute tests, the file conforms to our expectations of a legit procfs object. We then call fopen(3) on the file and access its contents. But... there's a problem here. What if the file we stat(2)ed is _not_ the same file we then call fopen(3) on? That is, what if the file was replaced with a different file between the 2 calls? What I'm describing here is a possible file based race condition.

My point is that you *cannot* assume anything when dealing with external input.
In writing these routines, I was doing things like attempting file open operations on jpg images of Ferraris, MS Word docs, PDF files, gzipped tar archives, etc. I wanted to see how ifchk would deal with, what is, in the context of a legitimate /proc/net/dev file, garbage.

I hope this answers your question.

> I think /proc is a great idea and somehow in line with UNIX overall philosophy (all is a "file").

This is one of the things that really stood out for me when I started working with Linux. I can now access in-kernel structures as if they were a text file. cat(1), less(1), fopen(3), fstat(2) on a proc file. No problem.

> I regret sometimes that the layout and the values of the/proc file system change from one OS version to the other, but maybe evolution requires that, so that's ok with me.

I comment on this, from within the context of sscanf(3), below.

> The real pity is not as much that its layout changes, but the fact that its documentation is often difficult to find and very poor.

This is where the Usenet archives shine. You can really piece alot together by sifting through the archives at groups.google.com. It's a _very_ powerful resource.

> In that respect I think this article is a great idea,..

Thank you. I'm glad you enjoyed it. I certainly had alot of fun writing it.

> ...but why so much "mistery" around it?

The more exploration one does, the more the mystery lessens. This is what I was getting at at the beginning of the article. Systems programming is like being able to view the internals of a running car engine, from all angles, in real time. That's enticing. And, like Usenet, powerful.

The Windows Registry is NOTHING like /proc. /proc gives you real time access to kernel parameters and the resources of running processes. /proc exists entirely in memory.

The Windows Registry, on the other hand, is a database of configuration paramaters. It's NOT real time, it does not contain info on running processes, and it does not give access to Windows kernel runtime parameters.

They are nothing alike.

> The proc filesystem should be used as a programming facility.

I agree.

> There are system calls for the same info.

Parsing proc files in /proc is a common way of accessing
in-kernel structures (netstat(8) and ifconfig(8) do this).
Sifting through the comp.os.linux.development.{system,apps}
Usenet group archive illustrates this.

> The format of the items in /proc can change from one kernel
> version to the next.

The programmer has to take care when dealing with conversion
specification in sscanf(3) calls, etc. He/she has to understand
the format of the proc object that is to be scanned.

> Not all systems have /proc mounted.

That's ok. This is where function return value checks are so important. The lstat(2) call in the article code (line 565)
returns error if it can't get to /proc/net/dev and we exit
gracefully.

> Also, not at flavours of Unix support /proc.

I wrote this piece from the perspective of the Linux system.

> This article is a bad idea.

Thanks for your feedback.

> This article is a bad idea.

You can't generalize that. For instance, most firewall shell scripts use the /proc file system, which is perfectly legitimate. The question is how far you want to push it, and the author is pushing it quite far.

Ultimately, this goes back to the "right tool for the right job" philosophy. And the /proc filesystem definitely has its place in the toolbox.