[Dazuko-devel] Re: [Dazuko-help] about memory leak of Dazuko (2.2.0.2)

[John Ogness]

address@hidden wrote:
> Could you please show me about details of these fixings? 
> 
> 2.3.2-pre2
> - fix name-cache leak for Linux 2.2, 2.4, and 2.6+syscall
>   (what is name-cache? when is name-cache leak happen? etc)

Upon closer examination of the problem, it is not related to the name
cache. The memory leak is related to filenames, which is probably why
the association to the name-cache was automatically made.

Nonetheless, it was a memory leak. The problem was that under certain
circumstances, memory was allocated but never freed. This situation
occurs when a file is created in a directory that is a symbolic link.
Example:

$ cd /tmp
$ mkdir dir1
$ ln -s dir1 dir2
$ touch dir2/file

The "touch" command will cause a single 5-byte leak (length of "dir2").
If the "touch" command had been:

$ touch /tmp/dir2/file

it would cause a single 10-byte leak (length of "/tmp/dir2").

These leaks occur because the file is created in a directory that is a
symbolic link. The leaks will begin occuring as soon as an application
registers with Dazuko (regardless of which IncludePaths are used). If no
applications are using Dazuko, there is no leak.

These leaks exist in the Dazuko versions between (and including)
2.1.0-pre4 and 2.3.2-pre1. The leaks are only present for Linux 2.2,
Linux 2.4, and (if configured with --enable-syscalls) Linux 2.6.

LSM-based configurations (the default for Linux 2.6), FreeBSD, and RSBAC
systems are not affected.

The patch, which fixed the problem is attached to this email. If you
need more information, please let me know.

John Ogness

-- 
Dazuko Maintainer

Index: dazuko_linux.c
===================================================================
RCS file: /cvsroot/dazuko/dazuko/dazuko_linux.c,v
retrieving revision 1.84
retrieving revision 1.85
diff -u -r1.84 -r1.85
--- dazuko_linux.c      2 Nov 2006 17:57:35 -0000       1.84
+++ dazuko_linux.c      14 Nov 2006 16:47:13 -0000      1.85
@@ -1042,6 +1042,12 @@
                        {
                                /* we will try to build a "fake" name from the 
parent directory */
 
+                               if (freeparentpath != NULL)
+                               {
+                                       /* This needs to be put if we are in 
the second loop
+                                        * because the parent was a link. */
+                                       putname(freeparentpath);
+                               }
                                freeparentpath = 
getname(dfs->extra_data->user_filename);
                                /* make sure it is a valid name */
                                if (IS_ERR(freeparentpath))