John Ogness | 1 Sep 21:02 2005
Picon

2.1.0-pre8 posted

Hi,

A number of important issues came up that needed to be fixed before the
official 2.1.0 release. These included:

1. Linux 2.6 LSM stacking was not working correctly. Even though modules
thought they were stacking on top of Dazuko correctly, their hooks were
never being called.

2. Linux 2.6 kernels without the commoncap module were having problems
when Dazuko was loaded. Dazuko's dummy capability function was not doing
what it should have.

3. For Linux 2.6.13 the device API was changed.

All three of these items have been fixed with 2.1.0-pre8 along with
support for suspend under Linux 2.6 and updated perl, python, ruby, and
lua language bindings.

2.1.0-pre8 is now far superior to 2.0.6 because of its many bugfixes and
enhancements. It is important that it is released soon. So far all
people who reported problems with 2.1.0-pre7 have verified that they
have been fixed. I consider 2.1.0-pre8 ready to be the official 2.1.0
release, but I will sit on it a week and see if anything turns up.

John Ogness

--

-- 
Dazuko Maintainer
(Continue reading)

Abhishek Nayani | 2 Sep 08:10 2005
Picon

Device file events

Hi,

In the Linux 2.6 code, dazuko_get_full_filename() ignores all device
files due to
this specific piece of code:

#ifndef DAZUKO_FIST
    if (!S_ISREG(xfs->inode->i_mode) && !S_ISLNK(xfs->inode->i_mode))
        return 0;
#endif

DAZUKO_FIST does not seem to be defined anywhere. Is there any specific
reason to filter
out /dev ? This is not so in the 2.4 codebase.

Regards,
Abhi.
John Ogness | 2 Sep 09:02 2005
Picon

Re: Device file events

Abhishek Nayani wrote:
> In the Linux 2.6 code, dazuko_get_full_filename() ignores all device
> files due to
> this specific piece of code:
> 
> #ifndef DAZUKO_FIST
>     if (!S_ISREG(xfs->inode->i_mode) && !S_ISLNK(xfs->inode->i_mode))
>         return 0;
> #endif
> 
> Is there any specific reason to filter out /dev ? This is not so in the 2.4 codebase.

Hi,

Dazuko uses LSM for Linux 2.6. LSM generates *many* events for devices and
directories, which caused many unnecessary context-switches resulting in
performance problems. For this reason Dazuko for Linux 2.6 was confined to
only generate events for regular files and links.

At some point we will be moving away from LSM because it is a huge
maintenance issue, is not suited for what we want, and is very difficult for
end-users to work with. Once we are away from LSM, we can once again allow
vnodes of all types.

John Ogness

--

-- 
Dazuko Maintainer
Tikka, Sami | 2 Sep 10:25 2005

__d_path export and SMP safeness

Dazuko on Linux 2.6 requires the use of __d_path function in the kernel (to
be SMP safe). __d_path is not exported in many kernels. A quick survey of all
the desktops around me reveals that Gentoo, Mandrake, Slackware and Debian
kernels do not export that function. Only Suse exports it.

Has there been any communication with the kernel developers about getting it
exported?

Has anyone contacted distributions about the problem?

--

-- 
Sami Tikka                tel. +358 9 2520 5115 
senior software engineer  fax. +358 9 2520 5014
                          mobile +358 40 7379388
F-Secure Corporation      http://www.f-secure.com
BE SURE
Tushar | 2 Sep 14:18 2005
Picon

Re: __d_path export and SMP safeness

On Fri, 2005-09-02 at 13:55, Tikka, Sami wrote:
> Dazuko on Linux 2.6 requires the use of __d_path function in the kernel (to
> be SMP safe). __d_path is not exported in many kernels. A quick survey of all
> the desktops around me reveals that Gentoo, Mandrake, Slackware and Debian
> kernels do not export that function. Only Suse exports it.
	Neither FC3.

There is one function d_path. In kernel source 2.6.8, it is exported.
(One downloaded directly from kernel.org). Can we use that? It
internally use the same __d_path function with locking and unlocking.	
> 
> Has there been any communication with the kernel developers about getting it	
> exported?
> 
> Has anyone contacted distributions about the problem?
--

-- 
Regards,
Tushar
--------------------
It's not a problem, it's an opportunity for improvement. Lets improve.
Tikka, Sami | 2 Sep 15:24 2005

RE: __d_path export and SMP safeness

>-----Original Message-----
>From: Tushar [mailto:tushar <at> mwti.net] 
>Sent: Friday, September 02, 2005 3:18 PM
>To: Tikka, Sami
>Cc: dazuko-devel <at> nongnu.org
>Subject: Re: [Dazuko-devel] __d_path export and SMP safeness
>
>There is one function d_path. In kernel source 2.6.8, it is 
>exported. (One downloaded directly from kernel.org). Can we 
>use that? It
>internally use the same __d_path function with locking and unlocking.	

Apparently d_path returns the pathname the process sees, which might be
different from the real pathname if the process is chrooted.

--

-- 
Sami Tikka                tel. +358 9 2520 5115 
senior software engineer  fax. +358 9 2520 5014
                          mobile +358 40 7379388
F-Secure Corporation      http://www.f-secure.com
BE SURE
Kai-Cheung Leung | 3 Sep 00:03 2005
Picon
Picon

possible bug in the code of dazuko_linux26.c in Dazuko 2.1.0-pre8

I have tried to compile dazuko-2.1.0-pre8 under Debian Sarge with gcc
3.3.5 and kernel 2.6.11  However it fails with the following messages:

abc <at> debian1:/DVD/src/dazuko-2.1.0-pre8$ fakeroot ./configure
checking host system type... Linux
checking for make utility... ok (make)
checking for C compiler... ok (cc)
kernel source in /lib/modules/2.6.11-1-686/build... yes
acquiring Linux kernel code configuration... ok
checking if Linux is RSBAC patched... no
checking if devfs is enabled... yes
discovered host system... Linux (2.6.11)
checking if security module support is enabled... yes
verifying capabilities are not built-in... ok
locating LSM API header... ok
identifying LSM API... ok
inspecting suspend function... ok (suspend1 or suspend2)
inspecting class type... ok (class_simple)
disabling ON_CLOSE events (not available for Linux 2.6)
configure: creating Makefile
configure: creating library/Makefile
configure: creating example_c/Makefile

./configure successful

=======================
 Configuration summary
=======================

module events = ON_OPEN ON_EXEC
(Continue reading)

John Ogness | 3 Sep 22:16 2005
Picon

2.1.0-pre9 posted

Hi,

As has been reported, there were problems with the new support for
suspend on Linux 2.6 kernels older than 2.6.13. This was actually a
problem with Dazuko's configure script, which was falsely identifying
the suspend API available in the kernel (the suspend API was changed for
2.6.13). This problem has been fixed in the new pre-release (2.1.0-pre9).

Also included in this pre-release was a last-minute change of the
logging priority for Linux 2.6. All Dazuko messages for Linux 2.6 are
now logged using KERN_INFO. This will prevent messages from showing up
in the console (which can be annoying since it messes up the pretty
startup sequence on most distributions).

Despite this recent problem with the configure script, I am still
planning the 2.1.0 official release for next week (8 September). Thank
you to everyone who has been testing the pre-releases. This has helped a
lot!

John Ogness

--

-- 
Dazuko Maintainer
Kai-Cheung Leung | 4 Sep 01:16 2005
Picon
Picon

problems of dazuko-2.1.0-pre9 in co-existing with capability.ko in debian kernel-image-2.6.x

I have tried out the new dazuko-2.1.0-pre9.  It now compiles perfectly in
pre 2.6.13 kernels.  However it still cannot be loaded if capability.ko
module exists in the /lib/modules/2.6.x/boot/ directory.

Therefore when you release the final version of 2.1.0 and make a debian
package, in the installation script, would you please include instructions
to move the capability.ko from /lib/modules/2.6.x/boot/ to a backup
directory and install the dazuko.ko into the /lib/modules/2.6.x/boot/
directory?

This will allow dazuko to run properly with the debian kernel-image-2.6.x
packages in the Debian system, which is a prerequisite before you try
asking someone to sponser your package!!  Once this is done, then if you
want, I could talk to the clamav debian package maintainers and I am sure
that they will be happy to sponser your package they also want to see your
package to be included in the debian repository so that they can use it as
a dependency package for their clamav.

Kai-Cheung Leung
John Ogness | 4 Sep 15:50 2005
Picon

Re: problems of dazuko-2.1.0-pre9 in co-existing with capability.ko in debian kernel-image-2.6.x

Kai-Cheung Leung wrote:
> Therefore when you release the final version of 2.1.0 and make a debian
> package, in the installation script, would you please include instructions
> to move the capability.ko from /lib/modules/2.6.x/boot/ to a backup
> directory and install the dazuko.ko into the /lib/modules/2.6.x/boot/
> directory?

Does Debian load the modules in alphabetical order? If "dazuko.ko" is
renamed to "adazuko.ko" does it work correctly? Is it not possible to
specify the order the modules are loaded?

It is allowed to load capability.ko as long as dazuko.ko is loaded first.

John Ogness

--

-- 
Dazuko Maintainer

Gmane