Re: Compile dazuko fails

Dirk Vornheder wrote:
> After installing kernel 2.6.14 dazuko 2.1.1-pre1 fails to compile:

Hi,

This was reported by Thomas Kosch a couple weeks ago. The latest version
in CVS does not have problems with compiling, but has been reported to
cause problems when the module is loaded.

$ env CVS_RSH="ssh" cvs -z3 \
-d:ext:anoncvs <at> subversions.gnu.org:/cvsroot/dazuko \
co dazuko

I have not yet had a chance to debug the kernel panic that Thomas posted.

John Ogness

--

-- 
Dazuko Maintainer

Re: Buildreport with linux 2.6.14-rc3

Thomas Kosch wrote:
> Too early been pleased. It can be compiled and loaded. But if I start
> then avgard the computer chrashed after random time.

Hi,

I have been unable to track down why you were getting the kernel errors
within dput(). However, I have installed 2.6.14 on a machine and done
many tests and have not experienced any problems with Dazuko. Are you
still having problems? Are you using the official 2.6.14 kernel?

John Ogness

--

-- 
Dazuko Maintainer

2.1.1-pre2 posted

Hi,

Dazuko pre-release 2.1.1-pre2 has been posted. There were significant
changes to the Linux LSM API for 2.6.14. This pre-release supports these
new changes.

John Ogness

--

-- 
Dazuko Maintainer

MODULE_INFO(supported, "external")

Hello!

John, would you like to add the macro in the subject to the dazuko Linux
sources? Apparently it would prevent the printing of "Module not supported by
SUSE/Novell. Kernel tainted" message on SUSE (and possibly others).

If you do not feel it is appropriate to add the macro, I think I will add it
to the dazuko sources we ship with our application. If I do that, do you feel
I should change MODULE_AUTHOR to point to our customer support instead of
linux_support <at> antivir.de that it says currently?

--

-- 
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

Re: MODULE_INFO(supported, "external")

Tikka, Sami wrote:
> John, would you like to add the macro in the subject to the dazuko Linux
> sources? Apparently it would prevent the printing of "Module not supported by
> SUSE/Novell. Kernel tainted" message on SUSE (and possibly others).

I will send email to our SuSE contact asking about this.

> If you do not feel it is appropriate to add the macro, I think I will add it
> to the dazuko sources we ship with our application. If I do that, do you feel
> I should change MODULE_AUTHOR to point to our customer support instead of
> linux_support <at> antivir.de that it says currently?

You may change the source as you wish as long as the copyright information
is intact and documented in your distribution.

John Ogness

--

-- 
Dazuko Maintainer

[PATCH] Use d_path if __d_path is not safe

Hello!

As we discussed 2 months ago, dazuko could use d_path when running on an
Linux 2.6 SMP system and __d_path is not exported. I have now implemented
that change as you specified (behaviour changes only for Linux 2.6 SMP
chrooted processes). [see attached email]

I have uploaded the patch to Savannah:
https://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4602

I hope you find it to your liking and include it into Dazuko source.

--

-- 
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

From: John Ogness <jogness <at> antivir.de>
Subject: Re: [Dazuko-devel] __d_path export and SMP safeness
Date: 2005-09-06 14:45:47 GMT

Tikka, Sami wrote:
> Dazuko could use the exported d_path. Then the filename the driver reports

Re: [PATCH] Use d_path if __d_path is not safe

Tikka, Sami wrote:
> As we discussed 2 months ago, dazuko could use d_path when running on an
> Linux 2.6 SMP system and __d_path is not exported. I have now implemented
> that change as you specified (behaviour changes only for Linux 2.6 SMP
> chrooted processes). [see attached email]
> 
> I have uploaded the patch to Savannah:
> https://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4602
> 
> I hope you find it to your liking and include it into Dazuko source.

Great! The patch looks good. I will be making some minor adjustments to it,
but for the most part it is really good. Thanks! I will try to get this done
this week.

The changes I will make are:

1. Moving the "chroot" flag out of the extra_data structure and into the
dazuko_core structure. I don't want dazuko_core accessing the extra_data
fields. (extra_data is a "black box" for dazuko_core)

2. Rather than leaving off the beginning "/", I will have the string
"chroot:" prepended. For example: "chroot:/bin/blah". This follows the
scheme I presented for the "event injector". It is something that will
become very important when we move to DazukoFS. It also has the benefit of
allowing new applications to detect these events by configuring "chroot:" as
an IncludePath.

My main concern is that existing applications (that do not support chroot)
will not be aware that they are missing events. I will probably build a

Re: [PATCH] Use d_path if __d_path is not safe

John Ogness wrote:
> Great! The patch looks good. I will be making some minor adjustments to it,
> but for the most part it is really good. Thanks! I will try to get this done
> this week.

Hi Sami,

I have added this functionality to CVS:

$ env CVS_RSH="ssh" cvs -z3 \
-d:ext:anoncvs <at> subversions.gnu.org:/cvsroot/dazuko \
co dazuko

I was able to add the same functionality by only modifying the
dazuko_linux26.c file, localizing this solution to Linux 2.6. Your patch
helped to make things pretty easy. Thanks!

As I mentioned before, chroot'd events will come in the form of:

chroot:/path/to/file

Applications that are able to work with such events should include the
"chroot:" path:

dazukoAddIncludePath("chroot:");

For Dazuko modules that understand this, the add will be successful. If
the add returns error, then the Dazuko module does not understand chroot
events.

Buggy close-modified events on Linux 2.4?

I'm playing with dazuko 2.1.1-pre1 and trying out the on-close-modified
event.

I've attached two "script" sessions on a RHEL3 system. 

The close.script was run in one terminal window where I compiled and
installed dazuko and run the example program that watches for events in /tmp
directory

The modify.script was run in another terminal where I first created one file
in /tmp and then modified it.

As you can see in close.script, the first OPEN and CLOSE printouts are from
the creation of the file in /tmp. This is correct.

But the modification of the file in /tmp is weird. It results in 2 OPEN
events and 2 CLOSE events, no CLOSE(modified) events.

Am I missing something, doing something wrong or is there a bug?

--

-- 
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

Re: Buggy close-modified events on Linux 2.4?

Tikka, Sami wrote:
> But the modification of the file in /tmp is weird. It results in 2 OPEN
> events and 2 CLOSE events, no CLOSE(modified) events.
> 
> Am I missing something, doing something wrong or is there a bug?

Hi,

The CLOSE(modified) has been disabled for 2.1.x. A CLOSE(modified) event
is quite complex if it is to be implemented "correctly". The way that it
was implemented in 2.0.x and earlier was very sloppy and unreliable. If
an application needs to know this information, it is best if the
application determines this itself.

This doesn't mean that the event is forever "banned", but for the moment
it is not going to be implemented.

As for the 2 OPEN and 2 CLOSE events, this probably occurs because
dup(2) is being called. This function has the same affect as an open(2)
and therefore causes additional OPEN and CLOSE events.

John Ogness

--

-- 
Dazuko Maintainer