White paper

Introduction
Overview
Interface Design: Things that need to be considered
Server Implementation: The LibGTop "server"

Introduction

Many modern UNIX systems like Solaris, BSD or Digitial Unix only allow priviledged processes to read information like CPU and Memory Usage or information about running processes.

  • BSD, for instance, doesn't have any other way to get those data than reading directly from @file{/dev/kmem} and you need to be in the @code{kmem} group to be able to read this.

  • Other systems, like Digital Unix, allow all users to get things like CPU and Memory statistics, but only root may read information about any process other than the current one (you may not even get information about your own processes if you're not root).

  • Linux has a very nice @file{/proc} filesystem, but reading and parsing @file{/proc} is very slow and inefficient.

  • Solaris is a bit better, but you still need to be in the @code{sys} group or even root to get some data.

Because of this system utilities like @code{ps}, @code{uptime} or @code{top} often are setgid kmem or setuid root. Usually, they're also very specific to the system they're written for and not easily portable to other systems without a lot of work.

This, of cause, becomes a problem for graphical tools like @code{gtop} - making a GTK+ program setgid or even setuid would be a security hole as big as you can drive the entire X11 source code through. For the GNOME project, we also needed some kind of library which provides all the required information in a portable since there's more than just one single program that wants to use them - for instance @code{gtop} and the @code{multiload}, @code{cpumemusage} and @code{netload} panel applets.