Next attempt to get dazukofs into mainline kernel?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Next attempt to get dazukofs into mainline kernel?

Lino Sanfilippo

Hi John,

are there already any plans from you side to start another attempt to
get dazukofs into mainline kernel?
What has still to be done before such an attempt could be started?

Greetings,
Lino

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


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

Re: Next attempt to get dazukofs into mainline kernel?

John Ogness-9
On 2009-12-15, Lino Sanfilippo <[hidden email]> wrote:
> are there already any plans from you side to start another attempt
> to get dazukofs into mainline kernel?

At the moment, no. I simply don't have time right now. I am also
anxiously watching to see if fanotify makes it in. If it does make it
in (which isn't yet certain), we can discuss if Dazuko should continue
or if it would be better for the Dazuko community to concentrate our
efforts on backing fanotify. (For example, writing a library to
provide the DazukoFS interface for fanotify.)

> What has still to be done before such an attempt could be started?

The only open issue from the previous submission that hasn't been
addressed is the comment[0] about Linux containers. The argument from
Eric Biederman was that DazukoFS should not use a global namespace,
but instead provide a per-filesystem namespace. This would mean, for
example, that the DazukoFS devices are dynamically created per
DazukoFS mount.

I am assuming that Eric is looking at things from the point of view of
a hosting provider, who wants to allow virtual hosts to each have
their own DazukoFS available. But I'm not sure if that's the direction
we want to go. (At least, not yet. Maybe in the future it could be a
configuration option.)

Right now I see DazukoFS as a global component for all
filesystems. Linux containers could be useful to allow untrusted
proprietary scanners to run on the system.

For example, if my company is required to use some proprietary
(closed-source) anti-virus solution on the server, I cannot trust that
software. But if I could run the software in a container and still
allow the software to perform online file scanning, then I could
reduce my concerns about what that software is doing. That is how
DazukoFS should work right now (but I've never tested it).

I think it would be helpful if someone could set up a system using
Linux containers to see if:

1. Does DazukoFS even work correctly with containers? (I expect yes.)

2. If a registered process is within a container, can it still perform
online file scanning for files outside of its container?  (I expect
yes.)

If we know DazukoFS's behavior with Linux containers, we can readily
discuss this issue when it comes up.

Aside from that, it would be good to review all the VFS hooks and make
sure DazukoFS is still doing everything correctly. The VFS-API is
slowly changing and DazukoFS may not be doing things properly
anymore. Comparing DazukoFS's code with eCryptfs is usually a good
idea, since eCryptfs is already mainline.

John Ogness

[0] http://lkml.org/lkml/2009/2/12/306

--
Dazuko Maintainer


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