ClamFS and DazukoFS

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ClamFS and DazukoFS

John Ogness-2
Hi,

At the LinuxTag conference in Berlin last May, I had a chance to talk
to several kernel developers about ideas, alternatives, and future
directions for Dazuko. One of the ideas that was mentioned was to base
DazukoFS on FUSE (Filesystem in Userspace).

http://fuse.sourceforge.net/

At first I wasn't very excited about this idea, but have since seen
many advantages to FUSE. The biggest one being that it provides a
common API for filesystems across different platforms (such as Linux,
FreeBSD, NetBSD, MacOSX).

Today I began looking into it more seriously and discovered ClamFS:

http://clamfs.sourceforge.net/

This is a FUSE-based filesystem that is conceptually identical to what
we have as a goal for DazukoFS. However, it has been "hard-coded" to
work directly with the ClamAV scanner. I was quite excited to see this
and quickly began hacking the ClamFS code to include the userspace
version of Dazuko (system=dummyos). Within 2 hours I had a fully
functional version of Dazuko based on ClamFS. :)

Although initially exciting, the performance was quite disappointing.
In fact, it is almost unbearable. It wasn't that the CPU was having to
do a tremendous amount of work, but rather that the userspace
processes didn't seem to be getting scheduled as often as they should
be (or in a manner that is inefficient for what I needed).

If the filesystem process itself would perform the file access control
instead of communicating with an external process (via sockets), the
performance would probably be more acceptable. (I'm sure the
communication between filesystem process and file access control
process could be optimized.)

What does this all mean? It means that I am considering changing
DazukoFS to be FUSE-based rather than a stackable filesytem in the
kernel. My main motivation for this is that stackable filesystems are
proving quite complex (especially if you want them to be able to stack
on any kind of filesystem). A FUSE-based solution simplifies this
greatly because the FUSE-based filesystem uses the common userspace
API to access the underlying filesystems, which abstracts all details
of the underlying filesystem. (I have yet to test if it would work
correctly for "advanced" features such as SElinux, Capabilities, or
more exotic filesystems such as the stackable ecryptfs.)

Another nice advantage of using FUSE is that Dazuko would become a
pure userspace project and not require any kernel files. This will
make it easier to compile and make it independent of the constant
changes within the Linux kernel.

However, the biggest penalty (I fear) will be performance. But this is
something that may be improved over time (especially since all
FUSE-based filesystems are interested in such an improvement).

I have not yet contacted the maintainer of ClamFS to ask if he is
interested in abstracting ClamFS to provide a generic "stackable"
FUSE-based filesystem. I am waiting to get more feedback. So please
send me some feedback!

I am also debating posting to the Linux Kernel mailing list to ask
their opinions. Would they prefer that DazukoFS is a kernel module or
FUSE-based?

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: ClamFS and DazukoFS

jim burns
On Sat August 25 2007 10:31:54 am John Ogness wrote:
> At first I wasn't very excited about this idea, but have since seen
> many advantages to FUSE. The biggest one being that it provides a
> common API for filesystems across different platforms (such as Linux,
> FreeBSD, NetBSD, MacOSX).

A big YES to FUSE, and a common api for unix-like OSs.

> Although initially exciting, [ClamFS's] performance was quite disappointing.

I use the Fuse based ntfs-3g to access my Windows partition. It is a little
bit slower than nfs, but acceptable. Maybe ClamFS is not optimized.

>  (I have yet to test if it would work
> correctly for "advanced" features such as SElinux, Capabilities, or
> more exotic filesystems such as the stackable ecryptfs.)

This will be important.

> I am also debating posting to the Linux Kernel mailing list to ask
> their opinions. Would they prefer that DazukoFS is a kernel module or
> FUSE-based?

Opening a dialog couldn't hurt. SuSE has a dazuko-kmp-${flavour} .rpm, but
fedora/livna doesn't. I suspect it would be easier to get distros to include
your software if it is not a kernel module.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: ClamFS and DazukoFS

Frantisek Hrbata-2
In reply to this post by John Ogness-2
Hi,

I just want to say that FUSE is really interesting project but from my point
of view it is not a good idea to use it for the on-access scanning.
I will try to explain why.

1) I think that FUSE should be used for a user-space filesystem implementation and
   not for changing existing filesystem behavior.

2) It is not possible to pass control down to the real filesystem driver like e.g.
   in LSM or FiST based filesystems. You have to use mappings from FUSE root
   to the real root in user-space like ClamFS does.

3) There are two paths how to access files. One via the real root and second via
   the FUSE(ClamFS) root. This means that only files accessed via the FUSE root will be
   scanned. So it is not possible to provide a real on-access scanning because
   users can access files via the real root which is not under on-access scanner control.
   
   Same problem is with LD_PRELOAD. This approach, I think, is used in one Eset's approach for
   on-access scanning.
   
   I think it is really wrong if a user is able to pass by an on-access scanner.

   You can solve this by changing access rights on the real root(directory). But what
   about system directories like /bin etc.

4) Performance, performance, performance ..... :(
   This will never be even close to the kernel based on-access scanner performance.
   All operations have to be implemented in the user-space not only operations needed
   by the on-access scanner. This means that all operations will be redirected to the user-space.
   In each operation you need to do mappings from the FUSE root to the real root. Look
   at the fixpath function in the clamfs.cxx file. Just compare it with the in kernel
   mappings(e.g. FiST).

--
Regards,

Frantisek Hrbata
GRISOFT, s.r.o.

tel.  : +420 549 524 011
mailto: [hidden email]


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: ClamFS and DazukoFS

John Ogness-2
On 2007-08-26, Frantisek Hrbata <[hidden email]> 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


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: ClamFS and DazukoFS

Frantisek Hrbata-2
On Mon, 27 Aug 2007 10:55:21 +0200
John Ogness <[hidden email]> wrote:

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

Provide it as an alternative solution is fine. More solutions == better.

I was confused with one paregraph which you wrote in the first email.

<cite>
What does this all mean? It means that I am considering changing
DazukoFS to be FUSE-based rather than a stackable filesytem in the
kernel.
</cite>

I think that switching DazukoFS completely to the FUSE is not good but
keeping it as an alternative to the DazukoFS based on FiST is fine.

--
Regards,

Frantisek Hrbata
GRISOFT, s.r.o.

tel.  : +420 549 524 011
mailto: [hidden email]


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: UNS: Re: ClamFS and DazukoFS

jim burns
In reply to this post by John Ogness-2
On Mon August 27 2007 4:55:21 am John Ogness wrote:
> I think we may still be interested in offering a FUSE-based version of
> DazukoFS as a "backup".

Well, if you think you can maintain 3 versions of Dazuko ... (Four, if you
include LSM vs. syscallls.)

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

I would hope reiserfs would be the next addition. Despite DazukoFS's problems,
its performance was much better than mainline 2.3.x.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: ClamFS and DazukoFS

John Ogness-2
On 2007-08-27, jim burns <[hidden email]> wrote:
> Well, if you think you can maintain 3 versions of Dazuko ... (Four,
> if you include LSM vs. syscallls.)

I have no intention of supporting LSM or syscalls in Dazuko v3. It
will be pure DazukoFS. However, now it will probably be available as a
kernel module and FUSE-based alternatives.

LSM and syscall hooking have been a nightmare with Linux 2.6. If
anyone is interested in continuing on that path, they are welcome to
take over maintainence of the 2.x branch.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel