In the following post, I will show how to suppress such unwanted error messages to make it much more easier to analyze the output of Valgrind for your own application.

Installing Valgrind

On Mac OS X you can use MacPorts to install Valgrind. You have to use valgrind-devel if you are on Snow Leopard, because Snow Leopard is supported in the current development version only. It's as simply as typing sudo port install valgrind-devel.

On Gentoo it can become a bit harder. The current stable version is 3.5 (like in MacPorts). If you try this version (at least on an unstable Gentoo like mine) with valgrind ls, you will get the following error:

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

The reason is a striped glibc. To work properly, Valgrind needs to overwrite some of the system functions the glibc provide. It does this by getting the symbols by name out of this library. This is of course not possible if all the symbol names are removed. You can prove this by executing nm /lib/ld-linux-x86-64.so.2. Gentoo provides a FEATURE=splitdebug, which adds debug libraries to the installation. Unfortunately setting this feature in /etc/make.conf, means setting it global. Gentoo is known as being configurable as no other distribution out there and of course we can set a feature for one program only. To do so, create a file called glibc in /etc/portage/env/sys-libs/ and add the following content to it.

FEATURES="splitdebug"

After a rebuild of glibc by executing emerge --oneshot glibc, we have a working Valgrind.

As all programs, Valgrind isn't perfect. Version 3.5 shows many false/positive hits on my system, but fortunately the development goes on. Currently there is no newer version available in the Gentoo tree. Anyway it is not necessary to build one yourself, to get a more recent version. Using layman and the overlay tree of Flameeyes will let you integrate the development version of Valgrind seamlessly into your system. For a general How-to of layman check out this Users' guide. In short, something like the following should be sufficient:

layman -a flameeyes-overlay
layman -s flameeyes-overlay
echo "=dev-util/valgrind-9999 **" >> /etc/portage/package.keywords
emerge valgrind

Installing the development version of Valgrind is optional of course.

Know your tools

One usage of Valgrind could be look like this:

valgrind --leak-check=full --leak-resolution=high ./VirtualBox

Beside other errors it also shows this error message on my system:

==27174==    at 0x4C26C09: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27174==    by 0x4C26CB9: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27174==    by 0xBA8967F: ??? (in /usr/lib64/libglib-2.0.so.0.2400.2)
==27174==    by 0xBA89E9D: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.2400.2)
==27174==    by 0xBA89F86: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.2400.2)
==27174==    by 0xC204847: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.2400.2)
==27174==    by 0xC1EB8A5: ??? (in /usr/lib64/libgobject-2.0.so.0.2400.2)
==27174==    by 0xC1ECE5D: g_object_newv (in /usr/lib64/libgobject-2.0.so.0.2400.2)
==27174==    by 0xC1ED494: g_object_new (in /usr/lib64/libgobject-2.0.so.0.2400.2)
==27174==    by 0x72A495F: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x72A0D4F: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x7289264: QGtkStyle::QGtkStyle() (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x7215DB6: QStyleFactory::create(QString const&) (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x6F5B7FC: QApplication::style() (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x6F61DFF: QApplicationPrivate::initialize() (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x6F61E88: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x6F61FF3: QApplication::QApplication(_XDisplay*, int&, char**, unsigned long, unsigned long, int) (in /usr/lib64/qt4/libQtGui.so.4.6.3)
==27174==    by 0x44BC38: TrustedMain (main.cpp:371)
==27174==    by 0x44C649: main (main.cpp:651)

If you analyze the backtrace, you see that something in libQtGui is leaking memory. I don't want to blame someone for it or make a statement if this is right or wrong, I just want to get rid of it, to be able to easily spot errors VirtualBox itself produce. To do so, add --gen-suppressions=all to the Valgrind call. This will produce something similar like this:

{
 Memcheck:Leak
 fun:memalign
 fun:posix_memalign
 obj:/usr/lib64/libglib-2.0.so.0.2400.2
 fun:g_slice_alloc
 fun:g_slice_alloc0
 fun:g_type_create_instance
 obj:/usr/lib64/libgobject-2.0.so.0.2400.2
 fun:g_object_newv
 fun:g_object_new
 obj:/usr/lib64/qt4/libQtGui.so.4.6.3
 obj:/usr/lib64/qt4/libQtGui.so.4.6.3
 fun:_ZN9QGtkStyleC1Ev
 fun:_ZN13QStyleFactory6createERK7QString
 fun:_ZN12QApplication5styleEv
 fun:_ZN19QApplicationPrivate10initializeEv
 fun:_ZN19QApplicationPrivate9constructEP9_XDisplaymm
 fun:_ZN12QApplicationC1EP9_XDisplayRiPPcmmi
 fun:TrustedMain
 fun:main
}

To let Valgrind ignore this error in the future, copy the text into a file vbox.supp and start Valgrind with --suppressions=vbox.supp. Viola, this specific error isn't shown anymore. The format used there is easy to understand and you can of course tweak this much more. E.g. you could replace some of the fun: entries by "...". This is a placeholder for one or more functions calls with any name. Beside making suppression rules more general you can of course add as much as you like. Adding a name at the top make it easy to identify the different rules. For all the possibilities have a look at the documentation. Just for the curious, Valgrind is using such a file itself. Have a look at /usr/lib/valgrind/default.supp. You may also have noted that the function names in the normal error message differ from the one in the suppression list. The former is in the demangled form and the later in the saved form. You could force Valgrind to print mangled function names by adding the --demangle=no parameter to the call. This becomes handy if you manually create suppression lists.

Conclusion

By using suppression rules for the own application, unimportant errors could be eliminated in the output of Valgrind. With this is in mind there is no excuse anymore for memory leaks in the self developed applications. Beside memory leaks, Valgrind also finds places where uninitialized variables are in use or where memory is used which isn't allocated by the application. Also these tests could be filtered out by suppression rules.

The hardware used, as already said, is a MacBook Pro 3,1 and a Western Digital My Passport Essential 500GB USB hard disk. Other combination may work, but I don't guarantee this, as always. Also you should be warned that anything I describe here could destroy your existing installation and I'm not responsible for that. Doing some kind of backup might be a good idea. Time Machine is easy to use .

Before we start, as usual, the credits for some sites I get my information from. This is mainly the Produnis blog, the Blog of Chris, the Ubuntu wiki and of course the guys around the Grub2 development.

Creating the EFI boot loader

Apple doesn't use the legacy BIOS to boot their machines, they use the Extensible Firmware Interface (EFI). This new way of booting operation systems is very flexible, as the name suggest, but has several drawbacks, like most of the standard operation system doesn't speaks it language. Although Linux can be configured to use EFI directly we will emulate a legacy BIOS in the following. For this we need a connector which makes EFI and Linux happy and let them both work smoothly together. This connector is Grub2, which is in development for several years now. It's the successor of Grub and is the standard in many popular Linux distributions these days. We have to build a version our self, for which an existing Linux installation is really helpful. I used my 64-bit Gentoo installation. First you have to find out if the EFI installation on your target Apple machine is 64 or 32-bit. You can do this by executing:

ioreg -l -p IODeviceTree | grep firmware-abi

This will return EFI64 or EFI32 respectively. In my case I need the 64-bit version, which is a little bit surprising when I consider that my MacBook Pro isn't able to boot a 64-bit Snow Leopard. Anyway, grab the latest version of Grub2 and unpack it on the Linux machine. Please note that you need a gcc with multilib support if you are targeting an architecture which isn't the same as the host one. Use the following to configure Grub2 and to build it. Of course you have to adjust the target architecture if it is a different one.

./configure --with-platform=efi --target=x86_64 --disable-werror
make

When this is finished you create the EFI package by executing

./grub-mkimage -d . -o bootx86.efi *.mod

Here I included all modules which are available. If size matter for you, you could of course make a selective choice on the modules included. I didn't test this myself, so you have to find out yourself which one are important.

Whipping the USB hard disk into shape

Next we have to prepare the USB hard disk for the new installation. In the following I assume your USB hard disk doesn't contain any valid data and could be reformatted without data lose. Make a backup of your data first if this isn't the case on your side. Apple uses the GUID Partition Table scheme to organize their partitions on a hard disk. This specification is part of EFI and remove many limitations of the Master boot record (MBR) scheme, which is widely used in the PC world. That is e.g. the disk size limitation of 2TB or the maximum of 4 primary partitions. You reformat your disk, using the Disk Utility application of Mac OS X. Make sure all existing partitions on the disk are unmounted. When necessary, change the partition scheme from MBR to GUID in the Options dialog of the Partitions window. Select the partitions count you want to use. You need at least 3 partitions to make Linux works fine. My partition scheme looks like in the following: As you can see I have 5 partitions configured. The first one is an additional Snow Leopard installation for testing. I also added a Data partition at the end for making the data transfer between the different operation systems as easy as possibly. LINUXBOOT is a small partition which will contain the EFI boot loader (size it 50MB or something like that). Linux Swap, obviously, will become the swap partition of the Linux installation. DISK1S5 is the Linux root partition itself. The Data partition has to be formated as Mac OS Extended. Don't use the Journaled version of HFS+, cause this makes trouble on the Linux side. The other partitions have to be formatted as MS-DOS (FAT).

After applying the changes we can add the EFI boot loader to the LINUXBOOT partition. The Apple EFI implementation is searching for a file with the efi extensions on all bootable hard disks. Mount LINUXBOOT and create a efi/boot directory on the root path. Copy the bootx86.efi file into the boot/ directory. As bootx86.efi is a Grub2 boot loader we need a valid Grub2 configuration file. The following grub.cfg shows the configuration for a Ubuntu 9.10 i386 installation. For the 64-bit version or any other version of Ubuntu the settings might be slightly different.

menuviewer="text"
timeout=10
default=0
set F1=ctrl-x
menuentry "ubuntu-9.10-desktop-i386"
{
 fakebios
 search --set -f /boot/vmlinuz-2.6.31-14-generic
 linux /boot/vmlinuz-2.6.31-14-generic root=UUID=4e140981-4ab3-41a2-a2fb-26b1287beb87 ro quiet splash noefi video=efifb
 initrd /boot/initrd.img-2.6.31-14-generic
}
menuentry "ubuntu-9.10-desktop-i386 single"
{
 fakebios
 search --set -f /boot/vmlinuz-2.6.31-14-generic
 linux /boot/vmlinuz-2.6.31-14-generic root=UUID=4e140981-4ab3-41a2-a2fb-26b1287beb87 ro noefi video=efifb single
 initrd /boot/initrd.img-2.6.31-14-generic
}
menuentry "ubuntu-9.10-desktop-i386 text"
{
 fakebios
 search --set -f /boot/vmlinuz-2.6.31-14-generic
 linux /boot/vmlinuz-2.6.31-14-generic root=UUID=4e140981-4ab3-41a2-a2fb-26b1287beb87 ro noefi vga=normal
 initrd /boot/initrd.img-2.6.31-14-generic
}
menuentry "Mac OS X"
{
 search --set -f /usr/standalone/i386/boot.efi
 chainloader /usr/standalone/i386/boot.efi
}
menuentry "CD"
{
 appleloader CD
}
menuentry "mbr"
{
 appleloader HD
}
menuentry "reboot"
{
 reboot
}

You have to change the root UUID to the one the Ubuntu installer will assign to your hard disk after installation. Just check the fstab file when the installation has finished. The first entry boots Linux with a splash image enabled. The second one is for the single user mode in the case something went wrong. Please note the video=efifb option, which enables the graphical mode in the boot phase.

Installing Ubuntu

Most of the installation process is straight forward and doesn't need any special attention. Download the version of your choice from one of the mirrors, burn it on CD and start the installation. You can select the CD as boot medium by pressing Alt when your Mac starts. When the installer ask for the partition scheme, you have to switch to "manual choice". Select the DISK1S5 (your what it is in your case) as the root / partition and change the filesystem type to ext3. Also remember the path to the system partition, cause you will need it later again. Select the swap partition and change its type to swap. Proceed with the rest of the installation until the last dialog. There select "advanced settings" and change the boot loader target from hd0 to /dev/sdXX, where you replace XX to the path you used previously in the partition tool.

If all went right you should be able to select the LINUXBOOT partition by pressing Alt when your Mac starts. After that Grub2 should shows up, you will be able to boot into your freshly installed Ubuntu.

Conclusion

In this post I showed how to easily add the possibility to boot Linux on your MacBook Pro. With the external USB hard disk solution, no internal valuable space is wasted. Of course the speed isn't the same as if the OS would be installed on the internal drive, but for testing software on different operation systems this is satisfactory. To increase the speed a little bit more, an external FireWire hard disk could be used.

The agony of choice

OpenVPN could be configured in many different ways. So first of all we have to decide which features of OpenVPN we will use. In its simplest variant OpenVPN could be used with one preshared static key. The advantage of this setup type is the easy configuration. The disadvantage is that only one client could be connected at the time. That is not what we want, so we will configure our setup to be using a Public Key Infrastructure (PKI). This allows more than one client to be connected at the time and it is possible to mark single keys invalid without affecting other client keys. The second question which has to be answered is, if we want use routing or bridging in our setup. Again, routing is simpler to set up and also a little bit faster than bridging. Bridging on the other side allows the tunneling of non IP protocols such as IPX, tunnel all the IP broadcast and make it possible to use the same subnet on the client side as on the server-side. Especially the last point is a nice feature as with routing all hosts on the server-side needs a routing table entry to find the connected clients. But my main reason for preferring bridging over routing is the broadcast feature of the first one. In my home network works a NAS station as a file server. This includes of course simple filesystem sharing with AFP and NFS, but also serves this box audio data with the Digital Audio Access Protocol (DAAP). DAAP is used by Apple in iTunes to share music with other clients in the network and that is what my NAS station does. This protocol, as well AFP, using broadcast messages (ZeroConf) to find some potential clients. So now it should be clear why I want bridging, it allows me to hear music or to simply connect to my file station without any interaction.

Building up a PKI

To create all necessary certificates and keys we are using the easy-rsa scripts from OpenVPN. They are located under /usr/share/openvpn/easy-rsa. First we change the vars file. On the bottom of the file are personal information defined which should be changed to fit to your environment. The entries looking as follow on my side (with a pseudo email address).

export KEY_COUNTRY="DE"
export KEY_PROVINCE="Sachsen"
export KEY_CITY="Dresden"
export KEY_ORG="64k"
export KEY_EMAIL="you@yourdomain.org"

You could also increase the KEY_SIZE from 1024 to 2048 within that file. This should make your keys unbreakable for the next few decades years. Now we are ready to create the master-key and the master certificate of the Certificate Authority (CA) by executing:

source vars
./clean-all
./build-ca

Please be aware that this will delete all previously created keys. Answering all questions with the default values should be sufficient. Next the key for the server has to be created.

./build-key-server server

You can again accept all default values. A challenge password is not necessary, but you have to sign the certificate. Now its time for our first client key and certificate. You could the following repeat again and again, for every new client you want allow to access the OpenVPN server.

./build-key client

Again, don't forget to sign the key. If you ever have to mark a client certificate invalid you could do it with the following command:

./revoke-full client

This will create or update a Certificate Revocation List (CRL) file which will be later used by the server to verify the certificate integrity of a connecting client. For now we create an empty one with

KEY_CN="" KEY_OU="" KEY_NAME="" $OPENSSL ca -gencrl -out keys/crl.pem -config $KEY_CONFIG

The last step in this key building marathon is to create a Diffie-Hellman key. This key will be used to initiate the secure channel between the two parties. Its created by:

./build-dh

Creating the server and client configuration

We start with the configuration of the server:

# set the path to the tap device
dev tap
dev-node /var/tmp/tap0
mssfix
tun-mtu 1500
 
# TCP or UDP server?
proto udp
port 1194
 
# CA and key files
ca /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/ca.crt
cert /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/server.crt
key /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/server.key
crl-verify /keys/crl.pem # this is opened after the chroot
 
# Diffie hellman parameters
dh /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/dh1024.pem
 
# bridge setup
server-bridge 192.168.220.1 255.255.255.0 192.168.220.50 192.168.220.99
mode server
tls-server
push "dhcp-option DNS 192.168.220.1"
 
ifconfig-pool-persist ipp.txt
client-to-client
 
# compression?
comp-lzo
 
# The maximum number of concurrently connected clients we want to
# allow.
max-clients 20
 
# It's a good idea to reduce the OpenVPN daemon's privileges after
# initialization.
user nobody
group nobody
 
# Put openvpn in a jail.
chroot /var/media/ftp/FLASH-DISK-01/addons/openvpn
 
# The persist options will try to avoid accessing certain resources on
# restart that may no longer be accessible because of the privilege
# downgrade.
persist-key
persist-tun
 
# where to log
log-append /var/media/ftp/FLASH-DISK-01/addons/openvpn/log/openvpn.log
 
# verbose level for debugging
;verb 4
 
# make sure the connection is kept alive
keepalive 10 120

For bridged mode it is essential that OpenVPN uses a TAP device and not the TUN device mode (see here for the reason). We use UDP as the transport protocol and enable compression. Also we want that OpenVPN drops its privileges after the initialization and chroot into a jail to make it a little bit more secure. As the subnet for clients 192.168.220.0/24 is used. That is the same as my internal network uses. OpenVPN is allowed to use addresses ranging from 192.168.220.50 to 192.168.220.99. You have to make sure that the FRITZ!Box (or any other DHCP server in your network) doesn't serve addresses from that range. Of course you could change some of the settings to your needs, but then you have to make sure they match the configuration of the client.

Next we create the client configuration, which looks as follow:

# Specify that we are a client and that we will be pulling certain
# config file directives from the server.
client
 
# The hostname/IP and port of the server.
remote xtestx.dyndns.org 1194
 
proto udp
dev tap
 
pull
 
mssfix
tun-mtu 1500
 
# SSL/TLS parms.
tls-client
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
 
ns-cert-type server
 
# Keep trying indefinitely to resolve the host name of the OpenVPN
# server. Very useful on machines which are not permanently connected
# to the Internet such as laptops.
resolv-retry infinite
 
# Don't enable this; It must be disabled for iTunes to find the iTunes
# server and for AFP broadcast in general.
#nobind
 
# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody
 
# Try to preserve some state across restarts.
persist-key
persist-tun
 
# Enable compression on the VPN link.
comp-lzo
 
# debug level
;verb 4
 
mute-replay-warnings
mute 20

You have to change the remote hostname to your needs. You may also add the full path to the certificates and keys depending on your client OpenVPN installation.

Next we pack all files up for the server and the client respectively. The server needs the following one:

server.conf
keys/ca.crt
keys/crl.pem
keys/dh1024.pem
keys/server.crt
keys/server.key

The client needs this one:

client.conf
keys/ca.crt
keys/client.crt
keys/client.key
keys/server.crt

Customizing the FRITZ!Box

Connect to your FRITZ!Box and copy all the server files to the usbstick. I created a directory openvpn under the /var/media/ftp/FLASH-DISK-01/addons path. Next we need the OpenVPN binary for the FRITZ!Box. You can get it here. Unpack the file and copy the openvpn binary to /var/media/ftp/FLASH-DISK-01/addons/bin on the FRITZ!Box. Make sure the file mode has the executable bit set for the user. All files are now on the right places, so we can adjust our start script. Add the following code to the startup.sh file.

# Add a nobody user
echo 'nobody:x:65534:65534:nobody:/:/bin/false' >> /var/tmp/passwd
 
# Add some groups
echo 'root:x:0:' > /var/tmp/group
echo 'nobody:x:65534:' >> /var/tmp/group
 
# Create a tap device for openvpn
mknod /var/tmp/tap0 c 10 200
 
# Start openvpn
${BASE}/openvpn/bin/openvpn --config ${BASE}/openvpn/server.conf --daemon

As you see, we add a new nobody user to the Linux system. Then the device node for the TAP device is created and at the end the OpenVPN server is started. As we using the bridged setup, we have to add the new device to a bridge. Fortunately we haven't to create one, cause the FRITZ!Box itself is working in bridged mode. You can confirm this by executing:

brctl show lan

To let the system automatically add our TAP device to the lan bridge, we change the internal FRITZ!Box configuration. Edit the /var/flush/ar7.cfg file with nvi and search for the string brinterfaces. There should be one section with the name lan. Simply add the new tap0 interface to the interfaces value. The section should then look like this:

brinterfaces {
     name = "lan";
     dhcp = no;
     ipaddr = 192.168.220.1;
     netmask = 255.255.255.0;
     dstipaddr = 0.0.0.0;
     interfaces = "eth0", "ath0", "tap0", "wdsup1", "wdsdw1",
                  "wdsdw2", "wdsdw3", "wdsdw4";
     dhcpenabled = yes;
     dhcpstart = 192.168.220.100;
     dhcpend = 192.168.220.200;
}

Now, as soon the tap0 interface is created it will be added to the bridge. The last important point in the server setup is to change the internal firewall to allow connections to port 1194 from the outside. Search for forwardrules in the ar7.cfg file and add this new rule:

forwardrules =
               "tcp 0.0.0.0:7777 0.0.0.0:22 0 # SSH-Server",
               "udp 0.0.0.0:1194 0.0.0.0:1194 0 # VPN-Server";

Thats all for the server. A reboot of the FRITZ!Box should start the new OpenVPN server. If you have trouble you should manually start the OpenVPN server and increase the debugging level, as shown in the above configuration with the keyword verb.

Setting up the client

On the client side we need the files we packed above. On Gentoo the OpenVPN configuration is located at /etc/openvpn. Copy the configuration, the certificates and the key file to that place. The OpenVPN start script of Gentoo looks for the configuration file, based on the start script name. So we have to create a link like this:

cd /etc/openvpn
ln -s client.conf openvpn.conf

By the way, this lets you configure more than one OpenVPN connection at the time. Just create a link in /etc/init.d with the new configuration name and link it to the openvpn start script.

To make a first attempt to start the OpenVPN connection type

/etc/init.d/openvpn start

If all goes well you should have a new device tap0 when you execute ifconfig. Also there should be a route set, which point to the tap0 device when the 192.168.220.0/24 subnet is the target. Of course now you should be able to connect to any host in your home network by the IP. I didn't experiment enough with the pushing of the name server from the OpenVPN server, instead I just added the FRITZ!Box as an additionally name server to my /etc/resolv.conf. So here is room for further experiments.

To let the OpenVPN client start at boot time add it to the default runlevel by executing:

rc-update add openvpn default

Also note that with the above configuration the client always try to reconnect to the server, even if the FRITZ!Box is rebooted, which is a nice feature.

Conclusion

This setup allows you to connect to your home network in a very secure way without loosing any functionality. You are able to browse network shares on the local network or using services like DAAP without any further interaction.  The public key infrastructure make this setup a candidate for small business installations. If an employee leave the company his certificate is simply revoked without affecting the access of other employees.