Website design used with permission from H+BEDV Datentechnik GmbH

HOWTO Install There are 4 basic steps to running Dazuko. However, you should have experience with compiling the Linux kernel. If you do not have this experience, it is suggested that you give it a whirl. Building your own kernel not only allows your system to run optimally, but also gives you a chance to work with and get a feel for the heart of the GNU/Linux operating system. Note: If you already have the source code to your kernel and simply want to build Dazuko without building a new kernel, then you can. However, you need to be certain that the source code you have is really the same as the kernel you are running. Even though you have the kernel source code, it may not be configured. See FAQ#6 for more information about this. Step 1: Get your kernel source code Dazuko is a kernel module. Once a kernel module is loaded, it becomes one with your kernel. Therefore, Dazuko will call and share the same set of functions as the kernel. This is why the kernel source code is required in order to build Dazuko. It is not enough to just download the Linux source code. It must also be correctly configured to match your kernel. It is highly recommended that you first build and install a kernel. Then it is certain that the Linux source code you have is ok. If you do not know how to do this, read the opening paragraph above. Many distributions provide packages with the kernel source code. If you do not plan on building a new kernel, make sure you install the proper kernel source packages for your distribution. See FAQ#6 for information about configuring your kernel source code. Step 2: Compile Dazuko Once the source code for your running kernel is available, you can build Dazuko. First a Makefile must be generated by running: ./configure This will determine what kind of system you have and any special flags that need to be set. Then you can compile Dazuko with: make This will create a "dazuko.o" file as output, as well as a couple example programs. If you get any warnings or errors from either of the steps above, something is not correct. Make sure that the kernel source code is available and that it is correctly configured. Please read over the FAQ if you encounter problems. Step 3: Insert Dazuko Once you have successfully compiled Dazuko, the final step is to insert the module into the kernel. To do this, you must have root priveledges. This can be done with the command: /sbin/insmod dazuko.o If you don't get any messages, this is a good sign. To check if the module has been loaded type: cat /proc/modules You should see "dazuko" listed. If it is listed, then you should check to make sure that it successfully started the Dazuko device. This is done with: cat /proc/devices Again, you should see "dazuko" listed along with the device major number. For example purposes, I will assume this number is 254. Unless you are using devfs, you must create the device node. This allows applications to interact with Dazuko (with devfs the device node is created automatically). Assuming the major device number is 254, the commands to create the device node are: mknod -m 600 /dev/dazuko c 254 0 chown root:root /dev/dazuko Step 4: Test Dazuko So you've got Dazuko compiled and inserted into your kernel. Now what? Once Dazuko is running, an application is able to handle file access control through the Dazuko device. To test Dazuko it is recommended that you try out the example program (which was compiled when you compiled Dazuko). For security reasons Dazuko will only operate with processes that are running as root. Therefore you need to be root when you run the example program. Note: Dazuko 2.0.0 comes with a version of the example program that requires a list of paths to "watch" as arguments. ./example or from the Dazuko 2.0.0 package ./example /home /usr/home Once the example program is running, open up another terminal or shell. Open up some file within the /home directory (or any subdirectory thereof). As the files are accessed, the example program should output various information. The example program always permits the accesses, however another application could be written that denies file accesses in certain conditions. This allows a 3rd party to write complex file access control schemes (or customized file access logging utilities).