Re: ClamFS and DazukoFS

On 2007-08-26, Frantisek Hrbata <[email protected]> wrote:
> 3) There are two paths how to access files
>    [...]
>    I think it is really wrong if a user is able to pass by an
>    on-access scanner.

I think this depends a lot on the application. When used in a server
environment, I think it is quite appropriate that there are two paths
to access files. It is easy to restrict client-access to only the path
that is being controlled.

For workstations it becomes quite tricky. (Even with stackable
filesystem kernel modules it becomes quite tricky if you want '/' to
be covered.) As you mentioned, you can certainly use some permission
and chroot(8) tricks, but it isn't easy.

> 4) Performance, performance, performance
     [...]
>    All operations have to be implemented in the user-space not only
>    operations needed by the on-access scanner.

This is a very good point. The vast majority of operations are not
interesting for Dazuko. It is quite painful to send _everything_ to
userspace so that Dazuko can gain a few hook.


I think we may still be interested in offering a FUSE-based version of
DazukoFS as a "backup". The Dazuko project has been experiencing
severe compatibility problems over the past 2 years. By providing a
FUSE-based solution, we offer a non-kernel alternative. The
alternative may be less performant and include limitations, but it is
an alternative nonetheless.

An example would be if someone is using some exotic filesystem on
their server that DazukoFS does not correctly stack upon. The person
would then have the option to use the FUSE-based solution, which will
more likely be able to work.

This would also allow us to focus DazukoFS on ext2/ext3 for a while
because users could choose the FUSE-based solution for other
filesystems.

John Ogness

-- 
Dazuko Maintainer