LibGTop White Paper
*******************

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 /dev/kmem and you need to be in the 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 /proc filesystem, but reading and parsing /proc is very slow and inefficient.

  * Solaris is a bit better, but you still need to be in the sys group or even root to get some data.

Because of this system utilities like ps, uptime or 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 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 gtop and the multiload, cpumemusage and netload panel applets.

Overview
========

This section should give you a short overview on how LibGTop was developed, which things needed to be considered and how it works.

Interface Design
----------------

At the very beginning, it was necessary to collect all the data the library part should provide and put them into some C structures. This was not that easiy as it might sound since LibGTop should be portable to any modern UNIX system with a common library part on all those systems, but the data that should be returned vary from system to system. For instance some systems support shared memory, but some others may not.

The header files where we define these C structures (which are system-independent) are shared between client and server. This way we can call the system dependent code directly where we do not need any special privileges to do so.

All of those structures contain a flags member which is interpreted as a bit mask and tells the caller of the library functions which of the fields in the returned structure are valid and which are not.

Server Implementation
---------------------

The LibGTop server is a setgid/setuid binary which contains all the system dependent code which needs special privileges. It is only build if it's required on the current system (for instance, the Linux kernel provides all the required data via its /proc filesystem so we do not need the server at all) and it only contains the features which need privileges.

Whenever we do not need any privileges to get all the data for some of the requested structures (here called features) the library calls the sysdeps code directly rather than using the server.