[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] dazukofs and /dev/dazukofs.ign

From: Lino Sanfilippo
Subject: Re: [Dazuko-devel] dazukofs and /dev/dazukofs.ign
Date: Fri, 20 Feb 2009 11:53:28 +0100
User-agent: IceDove (X11/20090105)

Frantisek Hrbata schrieb:
On Fri, 20 Feb 2009 10:02:40 +0100
John Ogness <address@hidden> wrote:

On 2009-02-19, Frantisek Hrbata <address@hidden> wrote:
it there any particular reason to store task_struct pointer for
processes which should be ignored? This requires for multi-threaded
application to register each thread to dazukofs.

I cannot figure out what is this good for. Isn't tgid enough?
You have to define "enough". The ignore feature can be implemented
however we want. Like the old trusted feature, it is there for
applications to allow themselves to be ignored (as well as have some
control over _how_ they are ignored).

I just don't thing it is necessary to make a difference between threads
of one process. Basically because I think that trusted framework should
be used just for one purpose(described later).

Also I found following comment in the dazuko_linux26.c file.

/* Same thread id and same file descriptors,
 * looks like they could be the same process...
 * We will treat two threads of the same process
 * as the same (for relation checks). This is
 * useful for the Trusted Application Framework,
 * if we trust one thread, we can trust them all.*/

And I agree with this.

It is possible that a multi-threaded application only wants one of its
threads to be ignored because the other threads are doing tasks (such
as downloading files) that should _not_ be ignored.

I am not a big fan of this trusted thing, but it is needed. And from my
point of view, it is needed just for an AV's which are doing scan in a
different process then process which is accepting events(requests) from
dazuko. This is the only situation I am considering adequate to use
trusted framework.

AFAIK old dazuko supports whole process(including its threads) to be
trusted and all you need to do is to call dazukoRegisterTrusted just
once for each process.  Or am I missing something?
Actually that is only partially correct. Dazuko 2.x also uses the task
struct (individual threads) to implement the trusted feature. However,
dazukoRegisterTrusted() also had a flag DAZUKO_TRUST_CHILDREN that
would allow all the threads of the process and all children-processes
to be trusted.

I am aware of this. My option was that dazuko 2.x by default allows as
trusted process and all its threads. As I can see in the source code the
tgid is always checked.

call_xp_id_compare(check_related is set)
if (id1->tgid == id2->tgid && id1->files == id2->files)

More over I cannot not see that those checks are anyhow conditioned by
the DAZUKO_TRUST_CHILDREN. But maybe I am just missing something.

The DazukoFS ignore feature does not have such an option because I
could not find a safe method for traversing process trees. But we
could expand the feature to allow configuring it to trust all threads
of a process. This is technically not necessary. It would only be
there as a convenience for developers.

John Ogness

I agree. This is just a step forward to developers, but I would find it
Now why I am interested in this. I would like to implement(just
experimental) support for dauzkofs to our avg8 on-access scanner. The
reason for this is that I would like to have some performance
comparision dazukofs vs. avflt since there is none.

Dazuko-devel mailing list

To be honest, I dont see the reason to handle process ignoring within the kernel at all,
(as well as the group handling).
Those are things that should IMHO be done in userspace (maybe by
a daemon at which application can register for file accesses or trust. This daemon could
be the ONLY allowed application to communicate with dazuko).
There may be applications that would like to handle process trusting and group handling in a totally different way (i.e by using config files that specify which applications to consider as trusted, or using certificates or another authorization scheme to allow trusts).

It would also make the kernel code less complex without the group/ignoring implementation,
and thus a lot more stable.

Lino Sanfilippo

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]